Sign release binaries with GitHub build provenance attestations

Abierto Apto para principiantes
  • ¿Algo no está bien?
#3,038 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
62/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions
Área
ci-cd, release, security

Línea de trabajo

El cambio pertenece al flujo de trabajo cli-release.yml: revisa primero el bloque permissions existente del job y luego localiza dónde goreleaser genera dist/checksums.txt y dónde softprops/action-gh-release publica los assets. Añade el permiso attestations y un paso actions/attest-build-provenance entre esos dos puntos, tal como lo esboza el issue. Se considera terminado cuando el flujo de trabajo sigue ejecutándose y un asset compilado pasa gh attestation verify contra el repositorio.

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

Descripción

feature triage
What problem are you trying to solve?

Release assets are verifiable only against checksums.txt, published through the same channel. That detects a corrupted download; it cannot distinguish artifacts built by cli-release.yml from artifacts uploaded by anyone holding release permissions and able to update checksums.txt at the same time.

This matters a bit more since 0.19.0: devbox version update now replaces /usr/local/bin/devbox with the release binary itself, asking for sudo to do so. The downloaded binary is written to a root-owned path by the updater, where previously only the small launcher script lived there and the binary stayed under ~/.cache.

What solution would you like?

Attest the release artifacts in cli-release.yml. The job already has id-token: write; add

permissions:
attestations: write
and one step after goreleaser, before softprops/action-gh-release:

  • uses: actions/attest-build-provenance@v2
    with:
    subject-checksums: dist/checksums.txt

Keyless (Sigstore), no key to manage, no change to the published assets. Any download can then be verified with
gh attestation verify devbox_0.19.0_linux_amd64.tar.gz --repo jetify-com/devbox
and the launcher or version update could run the same check before installing.

Happy to ask my Muse Wonder to send the PR if you'd take it. We run devbox as the trust root of an agent fleet and adopt releases on day 0 (fail forward fast + report upstream fast); build provenance is the one check we can't do on our side. Thanks in advance, Pallieter @ CopyHosting & eBrain.

Alternatives you've considered

No response

Lenguaje dominante
Go
Estrellas
12.4k
Forks
358
Merge medio
17 h 12 min
PR fusionados (30 d)
31

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 jetify-com/devbox

Todos los issues de jetify-com/devbox

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.