Sign release binaries with GitHub build provenance attestations #3038

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