The two taiki-e/install-action pins in ci.yml point at commits that no longer exist in any branch, tag, or release of the upstream repo. They work today, but they are frozen at May 2026, dependabot silently skips them, and CI will break outright on a random future day if GitHub garbage-collects the orphaned objects. Supply-chain scanners (StepSecurity's imposter-commit detection) also flag them permanently, which teaches reviewers to shrug at that alarm here.
This is the same class as #626 (dtolnay/rust-toolchain pinned to a branch snapshot); this issue is the install-action remainder.
Expected
After the S-1.01 pinning campaign (#295), action pins are immutable SHAs that dependabot keeps current, as it already does for checkout, harden-runner, codecov, cargo-deny-action, and rust-toolchain in the same file.
Actual
Both install-action pins resolve, but neither is reachable from upstream history, and dependabot has never proposed an update for either (it cannot map an orphan SHA to a release version, so it skips the dependency):
| line |
pinned SHA |
comment says |
upstream reality (compare/HEAD...SHA) |
| 101 (coverage) |
e5de28ab |
# cargo-llvm-cov |
diverged, ahead 1 / behind 571 |
| 188 (mutants) |
aae1387a |
# install-action v2.x |
diverged, ahead 1 / behind ~470 |
Mechanism
taiki-e maintains moving per-tool convenience tags (@cargo-llvm-cov, @cargo-mutants, one per supported tool). Each is always exactly one commit on top of current main that flips the action's default tool:, and they are re-pointed frequently (most recently 2026-07-29). Resolving one of those tags to a SHA captures a snapshot that is guaranteed to be orphaned at the next refresh.
That looks like exactly what happened here: the coverage job used @cargo-llvm-cov before S-1.01 resolved it to the tag's then-current target (2026-05-07), and the mutants job (S-346, 2026-05-16) pinned the @cargo-mutants tag target from the same day. I verified both pinned diffs are the upstream maintainer's own two-line default-tool tweaks, so nothing malicious ever landed; the problem is durability and updatability, not content.
One trap for the fix: the coverage step passes no tool: input, so it currently depends on the orphan commit's default: cargo-llvm-cov. Repinning to a release SHA needs with: tool: cargo-llvm-cov added or the step fails on the now-required input. The mutants step already passes tool: cargo-mutants@27 and is a drop-in repin.
Ask
Could both pins move to the numbered release tag SHA (v2.85.4 = 065d6a08a14e61e89fb0a4c10eecdbdef39c7d8e), with tool: passed explicitly in the coverage step? That restores dependabot coverage and removes the garbage-collection exposure. PR follows.
The two
taiki-e/install-actionpins inci.ymlpoint at commits that no longer exist in any branch, tag, or release of the upstream repo. They work today, but they are frozen at May 2026, dependabot silently skips them, and CI will break outright on a random future day if GitHub garbage-collects the orphaned objects. Supply-chain scanners (StepSecurity's imposter-commit detection) also flag them permanently, which teaches reviewers to shrug at that alarm here.This is the same class as #626 (dtolnay/rust-toolchain pinned to a branch snapshot); this issue is the install-action remainder.
Expected
After the S-1.01 pinning campaign (#295), action pins are immutable SHAs that dependabot keeps current, as it already does for checkout, harden-runner, codecov, cargo-deny-action, and rust-toolchain in the same file.
Actual
Both install-action pins resolve, but neither is reachable from upstream history, and dependabot has never proposed an update for either (it cannot map an orphan SHA to a release version, so it skips the dependency):
compare/HEAD...SHA)e5de28ab# cargo-llvm-covaae1387a# install-action v2.xMechanism
taiki-e maintains moving per-tool convenience tags (
@cargo-llvm-cov,@cargo-mutants, one per supported tool). Each is always exactly one commit on top of current main that flips the action's defaulttool:, and they are re-pointed frequently (most recently 2026-07-29). Resolving one of those tags to a SHA captures a snapshot that is guaranteed to be orphaned at the next refresh.That looks like exactly what happened here: the coverage job used
@cargo-llvm-covbefore S-1.01 resolved it to the tag's then-current target (2026-05-07), and the mutants job (S-346, 2026-05-16) pinned the@cargo-mutantstag target from the same day. I verified both pinned diffs are the upstream maintainer's own two-line default-tool tweaks, so nothing malicious ever landed; the problem is durability and updatability, not content.One trap for the fix: the coverage step passes no
tool:input, so it currently depends on the orphan commit'sdefault: cargo-llvm-cov. Repinning to a release SHA needswith: tool: cargo-llvm-covadded or the step fails on the now-required input. The mutants step already passestool: cargo-mutants@27and is a drop-in repin.Ask
Could both pins move to the numbered release tag SHA (
v2.85.4=065d6a08a14e61e89fb0a4c10eecdbdef39c7d8e), withtool:passed explicitly in the coverage step? That restores dependabot coverage and removes the garbage-collection exposure. PR follows.