image(rust): pin rustup-init checksum via committed checksum files#158
Merged
Conversation
d1e1a79 to
8d252ca
Compare
2a17da7 to
73df312
Compare
3 tasks
5 tasks
f8a01ae to
adfdd85
Compare
dd83f01 to
1ba668e
Compare
30830d1 to
f9a4aa8
Compare
rustup publishes no signature for rustup-init, so it had no independent
trust anchor — the checksum file was previously fetched at build time
from the same server as the binary. Commit the checksum files
themselves (rust/rustup-init-{amd64,arm64}.sha256) instead of a raw
hash value in build.yaml, matching the existing pattern used for other
images' signing keys/keyrings, and bind-mount them into the Dockerfile
build for direct sha256sum -c verification against the exact upstream
file format.
ci: fold checksum-file syncing into update-material.yml
update-keys.yml and the now-removed update-checksums.yml both existed
to keep upstream-sourced trust material in sync with a scheduled PR,
duplicating the same download/diff/open-PR flow. Generalize
update-keys.yml (renamed update-material.yml, since its job is no
longer limited to signing keys) to support per-version URLs: an entry
can set version_file/version_key to have VERSION substituted from a
build.yaml before downloading, which is how the two new rustup-init
checksum entries pick up the currently pinned RUSTUP_VERSION. The
workflow also now runs on rust/build.yaml changes (in addition to its
own file and the weekly schedule) so a Renovate version bump gets a
checksum-update PR promptly instead of waiting for the next scheduled
run.
Fixed hardcoded references to the old update-keys.yml name in
release.yml and uv/Dockerfile comments, and added the new checksum
files to build-checks.yml's trigger paths so a housekeeper PR that
only changes them still runs the build/smoke-test/Trivy checks.
Verified rustup-init-amd64.sha256 against the live rustup-init binary
end-to-end (sha256sum -c reports OK).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rt6cdQY4Q3ie1xpMgyy33S
f9a4aa8 to
9131812
Compare
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
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.
Reworked based on feedback: instead of storing a raw checksum value in
build.yamland re-deriving it via a dedicatedupdate-checksums.ymlworkflow, commit the checksum file itself (rust/rustup-init-{amd64,arm64}.sha256), matching the existing pattern already used for every other image's signing key/keyring (bun/bun-signing-key.asc,mise/mise-minisign.pub,node/node-keyring.kbx, etc.).update-keys.ymlalready existed to keep exactly that kind of file in sync, so it's generalized (and renamedupdate-material.yml, since its job is no longer limited to signing keys) to support per-version URLs instead of introducing a second, near-duplicate workflow.Summary
rustuppublishes no signature forrustup-init, so it had no independent trust anchor — the checksum file was previously fetched at build time from the same server as the binary.rust/rustup-init-amd64.sha256/rust/rustup-init-arm64.sha256and bind-mount them intorust/Dockerfile's build for directsha256sum -cverification, instead of downloading a same-channel checksum file at build time.update-keys.yml→update-material.yml: an entry can now setversion_file/version_keyto haveVERSIONsubstituted from abuild.yamlbefore downloading, which is how the two new rustup-init entries track the currently pinnedRUSTUP_VERSION. The workflow also now runs onrust/build.yamlchanges (in addition to its own file and the weekly schedule) so a Renovate version bump gets a checksum-update PR promptly.update-keys.ymlname inrelease.ymlanduv/Dockerfilecomments, and added the new checksum files tobuild-checks.yml's trigger paths.Test plan
rust/rustup-init-amd64.sha256against the live rustup-init binary end-to-end (sha256sum -creports OK)build-checks.ymlbuildsrustsuccessfully with the committed checksum files on both architecturesworkflow_dispatchonupdate-material.ymland confirm the rust entries are no-ops