Four action pins name a version they are not, and nothing checks

[vladimirrott]

Every uses: in .github/workflows is pinned to a SHA with a version comment
beside it, which is the right shape: a tag is mutable and a SHA is not. Nothing
checks that the comment is true, and four of them are not.

FAIL  actions/deploy-pages              pinned cd2ce8fc but v5 is 368f8252
FAIL  taiki-e/install-action            pinned 37f7c578 but v2 is 5bf6ce01
FAIL  actions/dependency-review-action  claims v4, which is not a tag in that repo
FAIL  dtolnay/rust-toolchain            claims stable, which is not a tag in that repo

That block is the run from 2026-09-04. Recounted at d881d49 on 2026-09-06, the
four entries are the same four and one number has moved: v2 in
taiki-e/install-action now resolves to 84f5ac31, not 5bf6ce01. v2 is a
major alias the maintainers advance, so expect it to differ again by the time you
read this. The pinned SHA 37f7c578 has not moved, which is the point of pinning.

Recounted again at b2c823e6 on 2026-09-16. Two of the four entries have
changed, so read this list rather than the one above. Dependabot bumped three
actions in #405, and upstream moved two major aliases:

FAIL  github/codeql-action              pinned cdf488f5 but v4 is b96794f0
FAIL  taiki-e/install-action            pinned e67fa11c but v2 is 26e9283f
NOTAG actions/dependency-review-action  claims v4, which is not a tag in that repo
NOTAG dtolnay/rust-toolchain            claims stable, which is not a tag in that repo

actions/deploy-pages left the list: #405 moved it to 368f8252, which is the
head of v5, so its comment is now true. github/codeql-action joined it, and
it is the interesting one, because nothing in this repository touched it. The
pinned cdf488f5 is the head of v4.37.9; the v4 alias has since advanced to
b96794f0. A pin under a major-alias comment starts correct and drifts on
somebody else's release schedule, which is the whole argument for the convention
this issue settles.

Nothing is broken by this. Every pinned SHA still resolves and every workflow
still runs what it ran yesterday, which is exactly what pinning is for. What is
wrong is the audit trail: the comment is the only thing telling a reader which
version a forty-character hex string is, and four of them name a version that
SHA is not on. The last two name a moving reference rather than a tag at all,
so there is nothing for a reader to check against.

The check

lacs-project/sysknife has no pin verifier. vladimirrott/maintainer-agent has
scripts/verify-action-pins.sh, which now takes a repository root, so this
output came from pointing it at this checkout:

git clone https://github.com/vladimirrott/maintainer-agent /tmp/maintainer-agent
bash /tmp/maintainer-agent/scripts/verify-action-pins.sh .

Run it from the root of your sysknife clone. It takes a repository root as its
one argument and needs gh authenticated, because it resolves each tag through
the GitHub API.

Copying that script in and adding it to docs-and-hygiene is the whole fix. One
detail matters and is the reason not to write a fresh one: annotated tags point
at a tag object, not a commit. A naive comparison of refs/tags/X.object.sha
against the pin fails for every repository that signs its tags. I wrote that
naive version by hand first and it reported eleven failures instead of four,
including github/codeql-action, which is correctly pinned. A checker with that
flag rate teaches people to ignore it.

Two decisions in it

The two "not a tag" entries need a policy, not a bump. dtolnay/rust-toolchain@stable
and actions/dependency-review-action@v4 are branch or major-alias references.
Either the comment should say so, or they should be pinned to a real tag. The
trufflesecurity/trufflehog pin is the same shape and carries the same bare
comment, # main, so it needs whatever convention this issue settles on.

Bumping a pin is a supply-chain decision. deploy-pages and
install-action have moved by however many commits; updating the pin adopts all
of them. Worth reading what changed rather than taking the new SHA because a
checker asked.

Getting started

Everything here is a workflow file and one shell script. No VM, no daemon, no LLM
provider and no credentials beyond an authenticated gh.

The seventeen pins live in .github/workflows/:

grep -rhoE 'uses:\s*[A-Za-z0-9_.-]+/[A-Za-z0-9_./-]+@[0-9a-f]{40}.*' .github/workflows/ \
  | sed 's/^uses:\s*//' | sort -u

Resolve one comment by hand before you write any code, and use the annotated case,
because it is the one that will bite you:

$ gh api repos/ossf/scorecard-action/git/ref/tags/v2.4.4 --jq '.object.type, .object.sha'
tag
55891bbd73f2425e97637d96e306fc9d491d0b21
$ gh api repos/ossf/scorecard-action/git/tags/55891bbd73f2425e97637d96e306fc9d491d0b21 --jq .object.sha
2d1146689b8cda280b9bc96326124645441f03bc

55891bbd is the tag object. 2d114668 is the commit, and it is what the
workflow pins, so this action is correct. Compare against 55891bbd and you
report a failure on a pin that is right.

(This example used github/codeql-action@v4 until 2026-09-16. I swapped it
because the v4 alias moved upstream, so the old block now peels to
b96794f0 and teaches the opposite of what it was written for. v2.4.4 is an
exact version and stays put.) Four of the pinned actions carry annotated tags:
github/codeql-action, ossf/scorecard-action, Swatinem/rust-cache and
anchore/sbom-action. That is five of the seventeen uses: lines, because
github/codeql-action is pinned twice.

Lightweight tags skip the second call. gh api repos/actions/checkout/git/ref/tags/v7
returns commit and the SHA is already the commit, so branch on .object.type.

The new script belongs in scripts/, wired into the docs-and-hygiene job in
.github/workflows/ci.yml, and into scripts/ci-local.sh so a contributor gets
the same answer locally. #346 is the issue about those two lists drifting apart,
so add it to both.

Tests first

Two directions, and the second is the one that matters here.

Break what the guard protects. Add a fixture workflow whose uses: line pins
a real SHA under a version comment that names a different tag, point the checker
at it, and assert it exits non-zero and names that action. Then correct the
comment in the fixture and assert it exits zero.

Break the guard's own input. This checker has a specific way of being useless:
it can pass because it found nothing to check. Assert on the count, not just the
exit code. A fixture directory with three pinned actions must report three
verdicts, so that a regex which stops matching (a uses: written with different
spacing, a pin on its own continuation line) turns into a red test rather than a
silent green run over zero pins.

The annotated-tag case deserves its own test: pin github/codeql-action correctly
in a fixture and assert the checker calls it OK. That is the exact case a naive
implementation gets wrong, and it produced eleven failures instead of four when I
wrote the naive version by hand.

Difficulty

medium. The shell is short. Getting the tag peeling and the "not a tag" case
right is the work, and the fixture design above is most of the thinking.

[vladimirrott]

Deciding both open questions, so nobody picking this up has to wait on me. One of
them dissolves once you resolve the pins, and I had the premise wrong when I filed
this.

All four failures are comment fixes. No SHA moves.

I wrote that bumping a pin is a supply-chain decision. That is true in general and
it does not apply to any of these four, because every pinned SHA is already the
head of a real tag. The comment beside it names a different one.

$ gh api repos/actions/deploy-pages/tags --paginate --jq '.[] | select(.commit.sha=="cd2ce8fcbc39b97be8ca5fce6e763baed58fa128") | .name'
v5.0.0
v3.0.2-node.24
$ gh api repos/taiki-e/install-action/tags --paginate --jq '.[] | select(.commit.sha=="37f7c5781271959fb65b6b35224e28652ff2b63d") | .name'
v2.87.0
$ gh api repos/actions/dependency-review-action/tags --paginate --jq '.[] | select(.commit.sha=="a1d282b36b6f3519aa1f3fc636f609c47dddb294") | .name'
v5.0.0

So the three "moved" entries are # v5 on a SHA that is v5.0.0, # v2 on a SHA
that is v2.87.0, and # v4 on a SHA that is v5.0.0. The first two are a major
alias that advanced past the pin, which is exactly what pinning is for and costs a
reader only precision. The third is worse and it is the one I would fix first:

$ grep -rn 'dependency-review-action' .github/workflows/
.github/workflows/ci.yml:337:        uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294  # v4
$ gh api repos/actions/dependency-review-action/git/ref/tags/v5.0.0 --jq '.object.type, .object.sha'
commit
a1d282b36b6f3519aa1f3fc636f609c47dddb294

CI has been running v5.0.0 of the dependency review action under a comment that
says v4, since whenever that pin last changed. Nothing is broken and the comment
is off by a major version.

The fourth is a branch, and it should stay one

dtolnay/rust-toolchain@stable has no tag to move to:

$ gh api repos/dtolnay/rust-toolchain/tags --jq '[.[].name]'
["v1"]
$ gh api repos/dtolnay/rust-toolchain/branches --paginate --jq '.[].name' 2>/dev/null | grep -x 'stable\|master\|main'
master
stable

stable is a branch. The one tag that repo publishes is v1, which tells a reader
less than stable already does. Keep the branch reference.

The convention to enforce

• # v1.2.3 asserts "this SHA is the head of that tag". The checker resolves the
  tag, peels it when .object.type is tag, and fails on a mismatch.
• # main (branch) marks a deliberate moving reference. The checker reports it and
  passes.

Four comment lines change and no SHA does:

file:line	from	to
.github/workflows/ci.yml:337	# v4	# v5.0.0
actions/deploy-pages pin	# v5	# v5.0.0
taiki-e/install-action pin	# v2	# v2.87.0
dtolnay/rust-toolchain pin	# stable	# stable (branch)

trufflesecurity/trufflehog # main in .github/workflows/secret-scan.yml:36 takes
# main (branch) for the same reason. I claimed in the body that this pin already
carried a "tracks main by design" note. It does not, and it never has:

$ grep -rn 'trufflehog' .github/workflows/
.github/workflows/secret-scan.yml:27:  trufflehog:
.github/workflows/secret-scan.yml:36:        uses: trufflesecurity/trufflehog@05a583290be8c8f79852eb8741f5042920b47d00  # main
$ git log --oneline -S 'tracks main by design' --all

The git log -S returns nothing. I removed that sentence from the body.

What this changes for whoever takes it

The checker goes green in the same pull request that adds it, by editing five
comments and zero SHAs. That was the part I could not answer when I filed this, and
it is why the issue sat. Nobody has to make a supply-chain call to land it.

Bumping deploy-pages from v5.0.0 and install-action from v2.87.0 to their
current heads is still worth doing and is still a decision with reading behind it.
That belongs in its own issue, after the checker exists and can say what drifted.

[vladimirrott]

@be-student reserved for you as a follow-up to your recent work; the why is on your PR thread. No pressure and no deadline. Reply here and it is formally yours.

[vladimirrott]

@be-student measured every pin against upstream today while reviewing something else, so you have current numbers rather than the ones in the issue body. Nothing here changes what you were offered; it narrows it.

Seventeen uses: pins across the workflows. Twelve resolve exactly to the tag their comment names. Five do not, and they fail in three different ways, which is the part that matters for whatever check you write:

action	comment	pinned	that tag today	why it differs
github/codeql-action/{init,analyze}	v4	cdf488f5	b96794f0	tag moved under the pin
taiki-e/install-action	v2	e67fa11c	c3ec0de9	tag moved under the pin
actions/dependency-review-action	v4	—	no v4 ref exists	comment names a series, not a ref
dtolnay/rust-toolchain	stable	—	branch, not a tag	deliberate
trufflesecurity/trufflehog	main	—	branch, not a tag	deliberate

Three things I got wrong first, so the checker you write does not have to:

github/codeql-action/analyze is a subpath. Resolving repos/github/codeql-action/analyze/git/ref/tags/v4 returns 404 and reads as "no such tag" when the tag exists on the repository. Strip everything after the second path segment before asking.

@stable and @main are branches. Querying refs/tags for them 404s too, and that is correct behaviour, not a finding. A checker that reports those as errors will be turned off within a week.

actions/dependency-review-action has no v4 ref at all: its tags run v4.8.3, v4.9.0, v5.0.0. So the comment cannot be verified against anything, and separately, upstream has shipped a major version this repo has not taken. That is a second finding hiding inside the first, and it is on the supply-chain boundary.

The interesting shape for the fix is that "the comment is wrong" and "the comment cannot be checked" are different verdicts and want different messages. A checker that collapses them will either nag about the two branch pins forever or stay quiet about dependency-review-action.

Take it or leave it as before, and no is still a complete answer.

[vladimirrott]

Recounted every pin at b2c823e6 and edited the body. Two of the four entries changed, and one of them is the argument for this issue in a single pair of commands.

actions/deploy-pages is correct now. #405 moved it to 368f8252, which is the head of v5, so its comment finally says what it is.

github/codeql-action took the empty slot, and nobody here touched it. The pinned cdf488f5 is the head of v4.37.9, while the v4 alias its comment names has advanced:

$ gh api repos/github/codeql-action/git/ref/tags/v4.37.9 --jq '.object.type, .object.sha'
tag
a35ac6e6798d72df5475948b28efb89edc2e19ca
$ gh api repos/github/codeql-action/git/tags/a35ac6e6798d72df5475948b28efb89edc2e19ca --jq .object.sha
cdf488f595d80d6e07e03d4674febd5ab45fa938
$ gh api repos/github/codeql-action/git/ref/tags/v4 --jq '.object.type, .object.sha'
tag
311b4ee155dcdab395044f00946f664bd51ff173
$ gh api repos/github/codeql-action/git/tags/311b4ee155dcdab395044f00946f664bd51ff173 --jq .object.sha
b96794f015dfd88f77b49b1c93e0fa7110f94c63

A pin under a major-alias comment is correct on the day it lands and drifts on somebody else's release schedule. Ten days, in this case.

I swapped the worked example in Getting started, and that one was going to cost whoever takes this an hour. It used github/codeql-action@v4, and the two calls in it now return 311b4ee1 and b96794f0 instead of fddeee1a and cdf488f5. Copy it today and you conclude that a correct pin is broken, which is the exact failure mode the example was written to prevent. It uses ossf/scorecard-action@v2.4.4 now:

$ gh api repos/ossf/scorecard-action/git/ref/tags/v2.4.4 --jq '.object.type, .object.sha'
tag
55891bbd73f2425e97637d96e306fc9d491d0b21
$ gh api repos/ossf/scorecard-action/git/tags/55891bbd73f2425e97637d96e306fc9d491d0b21 --jq .object.sha
2d1146689b8cda280b9bc96326124645441f03bc

Exact version, annotated tag, and it stays put.

Everything else in the body holds. Four of the sixteen actions carry annotated tags (anchore/sbom-action, github/codeql-action, ossf/scorecard-action, Swatinem/rust-cache), which is five of the seventeen uses: lines, and the convention I decided on 6 September is unchanged: a # vN.N.N comment asserts tag-head and the checker fails on a mismatch, # ref (branch) marks a deliberate moving reference and passes.

[vladimirrott]

@be-student releasing this one back to the pool, with nothing owed and no hard feelings.

I offered it on 7 September and added numbers on the 10th, and you have been busy with #331 the whole time, which is the right place for your attention. Carrying a second reservation you have not started helps nobody, least of all you.

If you want it after #331 lands, say so here and it is yours again that day.

[vladimirrott]

@QinXi-ai offering you this one, and the reason is #427 rather than the subject matter.

You replaced a hardcoded list of test names in scripts/ci-local.sh with a glob, then made the glob's empty case fail instead of pass:

$ grep -n 'no release/e2e shell tests discovered' scripts/ci-local.sh
283:        record FAIL 'hygiene: no release/e2e shell tests discovered'

#369 needs that same pair. It asks for a checker that reads every pinned uses: in .github/workflows/, resolves the version named in the comment beside the SHA, and fails when the two disagree, wired into docs-and-hygiene and into scripts/ci-local.sh. The body says to add it to both by pointing at #346, which you closed.

What mikevillari holds, so neither of you writes the other's patch

tests/release/release-rehearsal.test.sh:130 already asserts that every uses: is pinned to a 40-hex SHA, and #441, #442 and #444 are all about that extractor: a flow-style mapping it cannot read, a workflow it could not open, a directory named x.yml. Whether a pin is a SHA is his. Whether the comment beside the SHA names the version that SHA is on is this issue, and nothing in the tree asks that question.

Recounted at 30b9e315 this morning

Seventeen pinned uses: lines:

$ grep -rhoE 'uses:[[:space:]]*[A-Za-z0-9_.-]+/[A-Za-z0-9_./-]+@[0-9a-f]{40}.*' .github/workflows/ | sed 's/^uses:[[:space:]]*//' | sort -u | wc -l
17

Four of them still fail, peeling annotated tags the way the body's "Getting started" section describes:

$ peel() { r="$1"; t="$2"; o="$(gh api "repos/$r/git/ref/tags/$t" --jq '.object.type + " " + .object.sha' 2>&1)" || { echo "$r@$t NOTAG"; return; }; ty="${o%% *}"; sha="${o##* }"; if [ "$ty" = tag ]; then sha="$(gh api "repos/$r/git/tags/$sha" --jq .object.sha)"; fi; echo "$r@$t -> $sha (via $ty)"; }; peel github/codeql-action v4; peel taiki-e/install-action v2; peel actions/dependency-review-action v4; peel dtolnay/rust-toolchain stable; peel actions/deploy-pages v5
github/codeql-action@v4 -> b96794f015dfd88f77b49b1c93e0fa7110f94c63 (via tag)
taiki-e/install-action@v2 -> 76c2e6406e52637deed7160d77bded76bd83e06e (via commit)
actions/dependency-review-action@v4 NOTAG
dtolnay/rust-toolchain@stable NOTAG
actions/deploy-pages@v5 -> 368f82528645a54fb793d4d04e342629a3f51346 (via commit)

github/codeql-action is pinned at cdf488f5 under a # v4 comment and v4 peels to b96794f0. taiki-e/install-action is pinned at e67fa11c under # v2 and v2 is 76c2e640 today, where it was 26e9283f when I recounted the body yesterday. That one alias moved twice in two days on somebody else's release schedule, which is the argument for the issue in a single line. deploy-pages is correct and is in the block so you have a passing case to test against.

The two NOTAG entries need a decision rather than a bump, and the body names it: dtolnay/rust-toolchain@stable and actions/dependency-review-action@v4 are branch and major-alias references, so either the comment says so or the pin moves to a real tag. trufflesecurity/trufflehog carries # main and is the same shape.

The half I care about

Annotated tags peel through a tag object, so a naive comparison against refs/tags/X.object.sha reports a failure on github/codeql-action, ossf/scorecard-action, Swatinem/rust-cache and anchore/sbom-action, all of which are pinned correctly. I wrote that version by hand and it gave eleven failures instead of four.

The other half is yours already: assert the count. A fixture directory with three pinned actions has to produce three verdicts, so a regex that stops matching turns red instead of printing a clean run over nothing.

No deadline and no pressure. Reply here and it is yours; say nothing and I will take that as a no with no hard feelings.

[QinXi-ai]

Thanks for the offer — I’ll take this. I’ll keep the existing SHAs, verify the version comments with annotated-tag peeling and explicit branch annotations, and wire the checker into both CI entry points with count/assertion fixtures. I’ll leave the release pin extractor work in #441/#442/#444 to mikevillari.