store: prepare for signing-key rotation (canonical signer + staged second key)#12
Open
cyberb wants to merge 2 commits into
Open
store: prepare for signing-key rotation (canonical signer + staged second key)#12cyberb wants to merge 2 commits into
cyberb wants to merge 2 commits into
Conversation
Add a selectable signing key so the store can be switched to the new rotation key without a code change: - config: signing_key_active (default: old) + signing_key_new_base64 - crypto.NewSigner takes the active selection and the new key material; with 'old' (the default) it keeps signing with the existing key, so behaviour is unchanged - cmd/store: only decode the new key when active is 'new' - the new private key is injected from the 'signing_key_new_base64' Drone secret via config/*/secret.yaml + deploy-prepare.sh; it never lives in source - new key is base64-encoded so it is a safe single-line secret value To flip later: set signing_key_active: new and redeploy. Pairs with the snapd change trusting the new key's public half.
Replace the hand-assembled assertion text (wrong header set and framing, which is why the snapd fork had to disable signature verification) with snapd's canonical serialization: type, authority-id, primary keys, remaining headers lexicographically, body-length, sign-key-sha3-384, then body. Add the per-type required headers snapd validates (account-key: name/since; snap-declaration: publisher-id/timestamp; snap-revision: developer-id/timestamp). Use the request key as the snap-revision snap-sha3-384 primary key; the model's Sha384 json tag is 'snap-sha3-385' (a typo) so it parsed empty and was only ever masked by the disabled verification. Verified: every produced assertion (account-key, snap-declaration, snap-revision) passes snapd's real asserts.Decode plus independent raw openpgp signature verification, for BOTH the old and the new key. This is the prerequisite for removing the Syncloud signature-check hack.
cyberb
changed the title
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.
Phase 1 of rotating the syncloud signing key. Two coupled changes to the store (both touch
crypto/signer.go):1. Canonical signer — signatures now actually verify
The store hand-assembled assertion text with the wrong header set and framing for every type (
primary-key,publisher-id,developer-id,revision,sha3-384… and missing required headers likename). snapd verifies over its own canonical serialization, so these never matched — which is the whole reason the snapd fork disabled signature verification (SignatureCheckreturns nil).This rewrites signing to snapd's canonical form:
type,authority-id, primary keys, remaining headers lexicographically,body-length,sign-key-sha3-384, then body — plus the per-type required headers (account-key: name/since;snap-declaration: publisher-id/timestamp;snap-revision: developer-id/timestamp).Proven: a test emits each assertion (account-key, snap-declaration, snap-revision) and verifies it with raw openpgp (independent of the fork's disabled check), for both the old and the new key. Cross-checked out-of-band that all three also pass snapd's real
asserts.Decode+ signature verification.This is the prerequisite for removing the signature-check hack from the snapd fork (a later, separately-verified step).
Also fixes a latent typo surfaced by real verification:
model.SnapRevision.Sha384json tag wassnap-sha3-385, so it parsed empty; the snap-revisionsnap-sha3-384now comes from the request key (authoritative).2. Staged second signing key (not enabled)
crypto.NewSigner(logger, activeKey, newKeyArmored)— selectable key, defaults toold, so behaviour is unchanged.signing_key_new_base64Drone secret (added) viaconfig/*/secret.yaml+ci/deploy-prepare.sh, base64 single-line; never in source. Wired into uat + prod deploy steps.signing_key_active == new.New key:
public-key-sha3-384: NX7IJUak…(self-signature independently verified). Pairs with syncloud/snapd#5 which trusts its public half.To enable later
Set
signing_key_active: newand redeploy — after the fleet is on snapd#5, and after the canonical signer has shipped so verification stays honest.