Skip to content

ci(pins): dtolnay/rust-toolchain@v1 is a mutable tag at 22 sites — decide the pinning mechanism, then apply it uniformly #825

Closed

Description

@hyperpolymath

Finding

dtolnay/rust-toolchain is referenced at 22 sites across 8 workflows, every one of them at the mutable tag @v1:

Workflow Sites
rust.yml 6
security-policy.yml 4
ci.yml 4
tests.yml 5
release.yml 1
quality.yml 1
build-gossamer-gui.yml 1

@v1 is a moving tag: whoever controls it can change what these 22 jobs execute without a commit appearing in this repository.

Why it was not folded into #822

#822's acceptance criterion 2 asked for a SHA pin while fixing a duplicate with: key in build-gossamer-gui.yml. Converting one of 22 identical sites would have left it inconsistent with 21 siblings and produced the appearance of compliance without the substance, so it was deliberately deferred here rather than half-applied. See the #822 PR body for the reasoning in full.

Countervailing evidence — this may be lower severity than it looks

Three measurements argue against treating this as urgent, and they should be checked before any sweep:

  1. The lockfile already pins it. .github/workflows/actions.lock records
    'dtolnay/rust-toolchain@v1' -> commit: sha1-02cb101ec7c40f2c49e1d9714d64511d8e1b74de.
    governance / Actions lockfile verify is green as of chore(ci): refresh actions.lock so the lockfile gate goes green (#818) #823, so a silent retag of @v1 should be caught by the lock gate rather than executed unnoticed. That claim is untested — it needs a mutant before it is relied upon.
  2. The repo convention is symbolic refs, measured 40 tag/ref to 8 SHA across the workflow tree. A partial conversion makes the tree harder to reason about, not easier.
  3. hypatia main carries zero effective branch rules (rules/branches/main → [], with a positive control on metadatastician/IDApTIK returning 8 rule types). There is no sha_pinning_required in force here, so nothing is currently being violated.

Acceptance criteria

  • Decide the mechanism first, then apply it uniformly. Either (a) all 22 sites SHA-pinned with the version in a trailing comment, or (b) an explicit recorded decision that actions.lock is the pinning mechanism for symbolic refs in this repo. Not a mix.
  • Mutant proving the lock actually catches a retag: change the recorded commit for 'dtolnay/rust-toolchain@v1' in actions.lock and confirm governance / Actions lockfile verify goes red. If it does not, claim 1 above is false and option (b) is not available.
  • If (a): the same sweep covers every other mutable tag in the tree, not only dtolnay/rust-toolchain — enumerate them first and state the denominator.
  • governance / Actions lockfile verify and governance / Workflow security linter both still report success, with jobs > 0, on the PR carrying the change.
  • Whichever option is taken, record it where the next reader will find it rather than only in the PR.

Provenance

Found while fixing #822 (duplicate with: blocks introduced by #810). Filed separately per the standing rule that a new finding is an issue, not a merge blocker.

🤖 Generated with Claude Code

https://claude.ai/code/session_0113HQM9LVGkNCzU1WwkJZSV

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    choreRoutine maintenance with no behaviour changecicdCI/CD: workflows, actions, lockfiles, pins, runners, release gates

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions