verify: content against manifest runtime key; end-to-end example#10
Merged
Conversation
…example A content document is signed by a runtime key, but only the manifest declares which runtime key is authorized (its canary.runtime_pubkey), so verifying a content document standalone could only report a signature rejection. Add --expected-runtime-pubkey to verify: pass the manifest's runtime key and the content (or transaction) signature is checked against it. Without it the prior behavior holds, now with a note pointing at the flag. Extend examples/blog into an end-to-end site: add manifest.unsigned.json and the signed manifest.json, and rewrite the README to walk the whole flow - derive the three role keys, convert and sign the content, sign the manifest, then verify the manifest from its onion (signature, canary, origin binding) and verify the content against the manifest's runtime key. Both verify steps accept. The README explains why the content needs the manifest. All four example .json files regenerate byte for byte from the documented commands, which were run verbatim to confirm.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Acts on review feedback that the blog example stopped before showing Entangled's real value - the manifest -> runtime key -> content relationship - and that 'verify' could not actually verify the content.
verify: add
--expected-runtime-pubkey. A content document is signed by a runtime key, but only the manifest declares which runtime key is authorized (itscanary.runtime_pubkey). Pass that key and the content (or transaction) signature is checked against it; without it, the prior behavior holds, now with a note pointing at the flag.example: extend
examples/bloginto an end-to-end site. Addmanifest.unsigned.jsonand the signedmanifest.json, and rewrite the README to walk the whole flow - derive the three role keys, convert and sign the content, sign the manifest, then verify the manifest from its onion (signature, canary, origin binding -> accept, canary Fresh) and verify the content against the manifest's runtime key (-> accept). The README explains why the content needs the manifest.The keygen quickstart is simplified (no shell-magic fallback). All four example
.jsonfiles regenerate byte for byte from the documented commands, which were run verbatim to confirm. fmt, clippy -D warnings, build, and test green with --locked.