chore(ci): pin every action to a commit SHA - #794
Open
rustytrees wants to merge 1 commit into
Open
Conversation
The release job's own permissions are already minimal — `permissions: {}` at
the top, `id-token: write` only where cosign needs it — but every `uses:`
resolved through a mutable tag, and two of them (`dtolnay/rust-toolchain@stable`,
plus the `@vN` majors) move under the repo's feet by design.
That is the weak edge of the signing story. A compromised third-party action
runs *inside* the job that produces the artifact, before cosign signs it, so
the signature comes out valid over malicious output. The README's claim that
"a leaked GitHub token is not enough to ship a malicious binary" is true of
the token and not yet true of the toolchain around it.
All 31 refs across the six workflows now name a commit SHA with the previous
tag kept as a trailing comment, so Dependabot still recognises them and the
intended version stays readable. Only `uses:` lines changed; indentation,
list markers, and line counts are identical.
SHAs resolved from each action's published tag at the time of writing.
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.
Last slice of #789, and the only one that isn't a code change.
The release workflow's own permissions are already done properly —
permissions: {}at the top of the file, per-job grants,id-token: writeonly on the job that needs it for cosign. But everyuses:resolved through a mutable ref, anddtolnay/rust-toolchain@stableis a branch, which moves by design.That is the weak edge of the signing story rather than a bug. A compromised third-party action runs inside the job that produces the artifact, before cosign signs it, so the signature comes out perfectly valid over malicious output. The README's claim that "a leaked GitHub token is not enough to ship a malicious binary" is true of the token, and pinning is what makes it true of the toolchain around it.
All 31 refs across the six workflows now name a commit SHA, with the previous tag kept as a trailing comment so Dependabot still recognises them (
actions/checkout@3d3c42e… # v7) and the intended version stays readable at a glance.SHAs were resolved from each action's published tag at the time of writing:
3d3c42e5aac5ba805825da76410c181273ba90b13e5f45b2cfb9172054b4087a40e8e0b5a5461e7c924ae3a1cded613372ab5595356fb5720e22ba16043fb46d1a93c77aae656e7c1c64a875d1fc6a0afb8b3582c8e4def4969c97caa2f19720cb33a72f4cda84d5c5c54efe2404f9d843567869ab1699d4f06c13b6b1a9625abc9e6e439d9c05a8f2190e94d1434d08867e3ee9daa34448df10607b98908d295f6978faf089d4d20b00c7766989d076bb2fc7f16f9f17788090df1f26f669e9d70d6ae9567deba618b1216eba7f8039b0f8d131d5473787f0edce68Worth re-resolving these yourself before merging rather than taking my word for them — that's a one-line
gh api repos/<action>/commits/<tag> --jq .shaeach.I verified mechanically that only
uses:lines changed: line counts are identical per file, and indentation and list markers are preserved. Nothing else in any workflow was touched, so there is no behaviour change to test for — CI passing on this PR is the check.