Skip to content

Pin release signing key and verify by default#95

Open
volen-silo wants to merge 1 commit into
mainfrom
production-keys
Open

Pin release signing key and verify by default#95
volen-silo wants to merge 1 commit into
mainfrom
production-keys

Conversation

@volen-silo

@volen-silo volen-silo commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

Summary

Turns on signed-release trust for the release channel: the production release signing public key is pinned in the installers, and signature verification is now on by default for install.sh release / install.ps1 release — downloaded archives are verified against the pinned trust root before install.

What's in here

  • Pinned key + default-on (install.sh, install.ps1): the release public key is embedded as a constant; verification is mandatory by default on the release channel. Env overrides (ROCM_CLI_SIGNING_PUBLIC_KEY_PATH/PEM) remain as escape hatches. Multi-key support is present for future rotation.
  • Build-time guard (scripts/release_readiness.py): CI verifies built archives against the configured signing public key, so a private/public key mismatch fails at release time, not on users' machines.
  • Consistency check (scripts/verify_pinned_keys.py): asserts the pinned constants match the canonical docs/keys/ file and the CI signing key. Runs in CI (PRs + release/nightly), embedding-agnostic (shell/PowerShell/Rust).
  • Canonical key (docs/keys/rocm-cli-release-current-public.pem).
  • Dormant scaffolding: metadata pinning (therock.rs, empty sentinel) and the production-trust CI gate (ROCM_CLI_REQUIRE_PRODUCTION_TRUST, unset) are wired but inert until their inputs exist — no behavior change from them.

Safety / rollout

  • No stable latest release exists yet (only pre-releases + a draft), so releases/latest/download has nothing to serve — enabling default-on cannot break existing users.
  • The pinned public key was confirmed to match the private key in the CI secret.
  • Metadata + recipe-index pinning are intentionally deferred (they need hosted artifacts); do not set ROCM_CLI_REQUIRE_PRODUCTION_TRUST yet — it requires those inputs.

Validation

  • Pinned key is a valid RSA-2048 key and matches both installer constants.
  • Sign → readiness-verify chain proven end to end; wrong key rejected.
  • verify_pinned_keys.py + release_readiness.py self-tests, metadata unit tests, clippy, fmt, shell/YAML checks all green.

Suggested pre-merge check

Cut a tag (or use the v0.1.0-rc.1 draft) so CI signs with the current key and confirm the readiness step reports "signature verified" — the final on-CI proof.

🤖 Generated with Claude Code

Comment thread scripts/release_readiness.py Fixed
Comment thread scripts/release_readiness.py Fixed
Comment thread scripts/release_readiness.py Fixed
Comment thread scripts/verify_pinned_keys.py Fixed
Comment thread scripts/verify_pinned_keys.py Fixed
Comment thread scripts/verify_pinned_keys.py Fixed
@volen-silo volen-silo force-pushed the production-keys branch 3 times, most recently from b5293cb to f71bb1a Compare July 9, 2026 13:36
@volen-silo volen-silo requested review from fredespi and juhovainio July 9, 2026 13:41
Pin the production release signing public key in install.sh and
install.ps1 and require signature verification by default on the
release channel, so downloaded archives are checked against the pinned
trust root before install.

Guard the key end to end: release_readiness.py verifies built archives
against the configured signing public key (a key mismatch fails at
build time, not on users' machines), and verify_pinned_keys.py asserts
the pinned constants match the canonical docs/keys file and the CI
signing key. Both run in CI.

Metadata pinning and the production-trust CI gate are wired but dormant
(empty sentinel / unset variable) until their inputs exist.

Signed-off-by: Eugene Volen <Eugene.Volen@amd.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants