Feature request: minimum release age (cooldown) for resolved pins

Abierto
  • ¿Algo no está bien?
#132 3 comentarios 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github-actions, go
Área
cli, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area:cli feature-request

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-lock or gh actions-lock --relock manually, 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, pnpm minimumReleaseAge (on by default since pnpm 11), Yarn npmMinimalAgeGate, Bun install.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 sources actions.lock resolution 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. @v4 resolves to the newest v4.x.y tag 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-fix could additionally flag pins younger than the window (the pinact --verify-min-age equivalent), 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/cli RFC #13314, and github/roadmap).
Lenguaje dominante
Go
Estrellas
253
Forks
15
Merge medio
19 h 30 min
PR fusionados (30 d)
60

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/gh-actions-lock

Todos los issues de github/gh-actions-lock

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.