Repository navigation
ci(release): repin setup-bazel to the GENUINE v0.14.0 — the old pin was not in the action's history - #583
Closed
avrabe wants to merge 2 commits into
Closed
ci(release): repin setup-bazel to the GENUINE v0.14.0 — the old pin was not in the action's history#583avrabe wants to merge 2 commits into
avrabe wants to merge 2 commits into
Conversation
…as not in the action's history `release.yml` pinned `bazel-contrib/setup-bazel@5483a91b6e3ffac6092848f1dd7eafcfad203d80` with the comment `# v0.14.0 pinned`. That SHA is not v0.14.0 — tag 0.14.0 is e8776f58fb6a6e9055cbaf1b38c52ccc5247e9c4 — and it is not in the action repository's history at all: commits/<sha> 422 "No commit found" commits/<sha>/branches-where-head 422 github.com/.../commit/<sha>.patch Not Found search/commits?q=hash:<sha> 0 results tarball/<sha> HTTP 200 <- still served GitHub resolves `owner/repo@<sha>` across the whole fork network, so an object that exists only in a fork, or was orphaned, still downloads under the upstream name. That is the "imposter commit" class, and it sat on the release job since #205 (2026-06-17, v1.77). The signed falcon-v1.140.0 run's log records `Download action repository 'bazel-contrib/setup-bazel@5483a91…'`. IT WAS BENIGN — MEASURED. Extracted into an isolated directory and never executed, its tree is byte-identical to the genuine v0.14.0: 5483a91 (pinned) 20 files content tree-hash d9249affa4edfd11 e8776f5 (v0.14.0) 20 files content tree-hash d9249affa4edfd11 104e3ee (v0.19.1) 24 files content tree-hash 24710fabad65c309 <- control The control proves the comparison discriminates. So no release ran anything but v0.14.0's code; what was wrong is that nobody could have SHOWN that from the pin, and the object could vanish (breaking a release mid-tag) or — had it differed — run arbitrary code on the job that produces signed artifacts. This repin changes NO executed code, only provenance: from "an object nobody can locate" to "the release tag's own commit". It is deliberately NOT the 0.19.1 bump in #580: that is a version change on the signing path and should be judged on its own. (#580's new SHA 104e3ee IS genuinely 0.19.1 — but it kept the stale "# v0.14.0 pinned" comment, which is how this surfaced.) AUDIT, so this is not one of several: every SHA-pinned `uses:` in .github/ was checked for existence upstream, with a negative control (a fabricated SHA must read NOT-IN-UPSTREAM) and a positive one (real 0.19.1 must read IN-UPSTREAM). 3 distinct SHA pins; this was the ONLY one not in its repository. The first run of that audit was vacuous — `--jq '.sha[0:7]'` prints the string "null" on a 422 and read as present — and the controls are what exposed it. Not in scope, named: ~every other action in this repo is pinned by mutable TAG, not SHA. That is a broader posture question, not this defect. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG
Contributor
Author
|
Superseded by #588 — this exact commit is cherry-picked there ( |
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.
Signing-path change — auto-merge deliberately NOT armed; maintainer review.
release.ymlpinnedbazel-contrib/setup-bazel@5483a91…commented# v0.14.0 pinned. It is not v0.14.0 (that ise8776f5) and not in the action's history: commits API 422,.patchNot Found, commit search 0 — yet the tarball endpoint serves it (HTTP 200), because GitHub resolvesowner/repo@shaacross the fork network. Every release since #205 (v1.77, 2026-06-17) downloaded it; v1.140.0's log shows it.Benign, measured: extracted in isolation, never executed — tree byte-identical to genuine v0.14.0 (20 files, content hash
d9249affa4edfd11both), with a control (real 0.19.1: 24 files, different hash) proving the comparison discriminates. So this repin changes no executed code, only provenance.Scope: deliberately not #580's bump to 0.19.1 (a version change on the signing path, to judge separately — its SHA
104e3eeis genuinely 0.19.1, but it kept the stalev0.14.0comment, which is how this surfaced).Audit: all 3 distinct SHA pins in
.github/checked with negative + positive controls; this is the only one not in its repo. (The first audit pass was vacuous —--jq '.sha[0:7]'printsnullon a 422 — the controls caught it.)Out of scope, named: nearly every other action here is pinned by mutable tag, not SHA.
🤖 Generated with Claude Code
https://claude.ai/code/session_01HvusAXYbHLyv3uTzfBcMbG