Feature request: minimum release age (cooldown) for resolved pins
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by tracing the entry points for gh actions-lock, --relock, --verify, and --no-fix, focusing on how actions.lock references are resolved and checked. Compare the proposed --min-age behavior across initial pinning, relocking, ref narrowing, and verification, then clarify the fallback and configuration semantics before implementation.
Written by the indexing model from the issue text.
Description
Summary
Add an option to exclude releases published less than N days ago when resolving action references into lockfile pins — the same "cooldown" concept as pinact's -min-age, Dependabot's cooldown, or the npm ecosystem's minimumReleaseAge settings, applied to actions.lock.
Motivation
- Avoiding freshly-published releases is one of the cheapest supply-chain defenses. Recent research found that most compromised packages are detected and removed within about a week of publication (see https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html), so simply not adopting versions younger than a few days moves consumers out of the blast window.
- Automated update paths already have workarounds: tools like Renovate (
minimumReleaseAge) and Dependabot (cooldown) can gate their own update proposals. - But when a maintainer runs
gh actions-lockorgh actions-lock --relockmanually, the tool always resolves the current latest SHA. There is no substitute on this path — unless the tool itself offers an age gate, manual relocking can pull in a release published minutes ago.
Prior art
- Dependabot
cooldown(default-days,semver-*-days): version updates wait out a cooldown by default (3 days); security updates bypass it. Same vendor, same problem space. - npm ecosystem: npm CLI
min-release-age, pnpmminimumReleaseAge(on by default since pnpm 11), YarnnpmMinimalAgeGate, Buninstall.minimumReleaseAge. - pinact
-min-age/--verify-min-age: the direct predecessor for pinning GitHub Actions; filters candidate versions by tag commit date / release publish date, and can verify existing pins against the same floor. - action-locker
--min-age-days: a third-party lockfile tool with the same feature, including a fallback mode that walks back to the newest release that clears the age floor instead of hard-failing. - Renovate
minimumReleaseAge: feasible here because GitHub tag/release lookups expose release timestamps — the same data sourcesactions.lockresolution already touches.
Proposed semantics (strawman)
- A
--min-age <duration>flag and/or a lockfile/config field. - Applied wherever a version is selected: initial pinning,
--relock, and ref narrowing (e.g.@v4resolves to the newestv4.x.ytag that clears the age floor). - When no version satisfies the window: either fail-closed with a clear error, or fall back to the newest release that does (action-locker style) — open to maintainer preference.
--verify/--no-fixcould additionally flag pins younger than the window (the pinact--verify-min-ageequivalent), so CI can enforce the policy without restricting manual runs.
Notes
- Checked
gh actions-lock --help(v0.1.6): no age-related option exists. - I couldn't find an existing issue or discussion covering this (searched this repo's issues,
github/actions-lockfile,cli/cliRFC #13314, andgithub/roadmap).
- Dominant language
- Go
- Stars
- 253
- Forks
- 15
- Avg merge
- 19h 30m
- Merged PRs (30d)
- 60
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/gh-actions-lock
-
Fix mode unpins a reusable workflow call when the same repository is also used as a step actionOpen
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/gh-actions-lock#261 ·
Maintainers usually reply within 1 day
-
Dependabot drops an unchanged transitive dependency when bumping a composite actionPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 30/100
github/gh-actions-lock#257 · 1 comment ·
Maintainers usually reply within 1 day
-
--migrate-local-actions rewrites action files in nested worktrees and submodulesPossibly taken @aksestok claimed this 1 day ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 20/100
github/gh-actions-lock#253 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
github/gh-actions-lock#252 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
github/gh-actions-lock#247 · 1 comment ·
Maintainers usually reply within 1 day
All issues in github/gh-actions-lock
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
cmd/ebitenmobile: multi-language bindings run the complete generator twicePossibly taken @kumagi claimed this today. Openos:macos performance
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
hajimehoshi/ebiten#4011 · 1 comment ·
Maintainers usually reply within 1 day
-
agent-butler-finding chore
Difficulty 1/5 Under an hour Newbie friendliness 78/100
jordansmall/spindrift#6318 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Eyevinn/moqlivemock#166 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
JakeChampion/lang#14091 ·
Maintainers usually reply within 1 day