36 lines
2.0 KiB
Markdown
36 lines
2.0 KiB
Markdown
# Manifest signing migration
|
|
|
|
The installed launcher population currently pins the 3072-bit RSA public key in
|
|
`ptlinux/launcher-update-public.pem`. Release scripts also support OpenSSL
|
|
Ed25519 keys, but changing the Gitea secret before clients receive the new
|
|
public key would make all metadata unverifiable.
|
|
|
|
Use this staged migration when Ed25519 is adopted:
|
|
|
|
1. Generate the Ed25519 key pair offline. Keep the private key out of the
|
|
repository and record the public-key fingerprint through the normal release
|
|
review process.
|
|
2. Publish a normal RSA-signed transition release. That immutable archive adds
|
|
the Ed25519 public key and updater support, while its channel manifest still
|
|
verifies with the RSA key already installed on clients.
|
|
3. Verify the transition release from a clean pre-transition installation on
|
|
both stable and prerelease channel paths. Confirm rollback still verifies old
|
|
RSA-signed historical manifests.
|
|
4. Keep `manifest.json.sig` RSA-signed while enough installations move to the
|
|
transition release. If dual signatures are introduced, upload the Ed25519
|
|
signature under a separate filename; never change the meaning of the legacy
|
|
`.sig` asset for old clients.
|
|
5. Publish a second RSA-signed release that makes the updater choose signatures
|
|
by an authenticated algorithm and key identifier, and bundles a keyring with
|
|
both public keys. Its minimum updater compatibility must prevent an older
|
|
verifier from trusting metadata it cannot authenticate.
|
|
6. Replace the protected Actions signing secret only after the keyring release
|
|
is deployed and measured. Exercise stable discovery, prerelease discovery,
|
|
remote rollback, withdrawal publication, and tamper rejection with Ed25519.
|
|
7. Retire RSA verification in a later release. Retain the old public key for
|
|
immutable historical rollback metadata until those releases are outside the
|
|
supported rollback window.
|
|
|
|
At every stage, a failed or incorrectly signed tag remains immutable. Correct
|
|
the pipeline and publish the next semantic version rather than replacing assets.
|