Two independent defects in gh actions-lock v0.1.6 fix mode, both observed on a single
run over a 30-workflow public repository on Linux.
1. The management banner is not idempotent
Every fix-mode run prepends
# This workflow is managed by gh actions-lock.
without checking whether the line is already present. After repeated runs, 27 workflow files
carried duplicates; one (mirror.yml) had accumulated three copies:
# SPDX-License-Identifier: MPL-2.0
# This workflow is managed by gh actions-lock.
# This workflow is managed by gh actions-lock.
name: Mirror to Git Forges
Expected: the banner is inserted only when absent, so running fix mode twice is a no-op.
This makes fix mode's output unusable in CI or a pre-commit hook, because each run produces a
spurious diff.
2. Bare-SHA refs are rewritten to mutable tags
Fix mode rewrote immutable commit pins into floating tags, for example:
- uses: dtolnay/rust-toolchain@02cb101ec7c40f2c49e1d9714d64511d8e1b74de
+ uses: dtolnay/rust-toolchain@v1
This weakens supply-chain posture, and it is hard to reconcile with the tool's own
sha-as-ref advisory, which pushes in the same direction (recommending a tag over a bare SHA)
while GitHub's own hardening guidance recommends pinning to a full-length commit SHA.
Whatever the intended policy, silently rewriting an existing immutable pin to a mutable one
during a lockfile refresh is surprising and, in a repository that pins deliberately, a
regression. At minimum it deserves an opt-in flag rather than being the default.
Impact together
Because of these two, fix-mode output could not be committed as produced: the lockfile was kept
and every workflow-file rewrite had to be discarded with
git checkout -- '.github/workflows/*.yml'.
Related
The more serious issue in the same version — job-level reusable-workflow uses: refs being
invisible, which produces a missed desync, a false stale, and fix mode pruning a required
entry — is filed as #129.
🤖 Generated with Claude Code
https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
Two independent defects in
gh actions-lockv0.1.6 fix mode, both observed on a singlerun over a 30-workflow public repository on Linux.
1. The management banner is not idempotent
Every fix-mode run prepends
without checking whether the line is already present. After repeated runs, 27 workflow files
carried duplicates; one (
mirror.yml) had accumulated three copies:Expected: the banner is inserted only when absent, so running fix mode twice is a no-op.
This makes fix mode's output unusable in CI or a pre-commit hook, because each run produces a
spurious diff.
2. Bare-SHA refs are rewritten to mutable tags
Fix mode rewrote immutable commit pins into floating tags, for example:
This weakens supply-chain posture, and it is hard to reconcile with the tool's own
sha-as-refadvisory, which pushes in the same direction (recommending a tag over a bare SHA)while GitHub's own hardening guidance recommends pinning to a full-length commit SHA.
Whatever the intended policy, silently rewriting an existing immutable pin to a mutable one
during a lockfile refresh is surprising and, in a repository that pins deliberately, a
regression. At minimum it deserves an opt-in flag rather than being the default.
Impact together
Because of these two, fix-mode output could not be committed as produced: the lockfile was kept
and every workflow-file rewrite had to be discarded with
git checkout -- '.github/workflows/*.yml'.Related
The more serious issue in the same version — job-level reusable-workflow
uses:refs beinginvisible, which produces a missed desync, a false
stale, and fix mode pruning a requiredentry — is filed as #129.
🤖 Generated with Claude Code
https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm