Add SLSA build provenance attestations to release artifacts

[clouatre]

Please explain the motivation behind the feature request.

Goose binaries are downloaded and executed in CI/CD environments (e.g., setup-goose-action). Currently, release artifacts have no cryptographic verification mechanism. Consumers cannot verify that binaries were built by block/goose's GitHub Actions. GitHub Artifact Attestations (GA since May 2024) provide zero-config SLSA v1.0 provenance.

Describe the solution you'd like

Add SLSA provenance attestations to release binaries using GitHub's attest-build-provenance action.

permissions:
  id-token: write
  attestations: write

- uses: actions/attest-build-provenance@v3
  with:
    subject-path: 'path/to/binary'

Consumers verify with:

gh attestation verify goose-linux-x86_64 -R block/goose

Describe alternatives you've considered

• Manual checksums (SHA256 files) - requires key management, no provenance
• Cosign signing - more complex setup than GitHub's built-in attestations
• No verification - current state

Additional context

• GitHub Artifact Attestations docs

• SLSA Provenance specification

• OpenSSF Scorecard - Signed Releases

• [x] I have verified this does not duplicate an existing feature request

[clouatre]

I'd like to implement this. I've analyzed the release workflows and have a straightforward implementation approach.

Proposed Implementation

Files to modify: 2 (.github/workflows/release.yml, .github/workflows/canary.yml)
Lines added: ~22 total (11 per file)
Changes:

1. Add attestations: write permission (already have id-token: write)
2. Add attestation step after artifact download:

- name: Generate artifact attestations
  uses: actions/attest-build-provenance@v3
  with:
    subject-path: |
      goose-*.tar.bz2
      goose-*.zip
      Goose*.zip
      *.deb
      *.rpm
      download_cli.sh

This covers all 11 release artifacts with glob patterns.

Evidence

Proven pattern: astral-sh/uv (74k+ stars, Rust) uses this exact approach:

• Same permissions: attestations: write, id-token: write, contents: write
• Same glob pattern strategy in subject-path
• Implemented in their announce job after downloading artifacts

Official docs: GitHub's artifact attestations guide confirms this pattern for multiple artifacts.

Testing: Canary workflow will automatically test on merge. Verification:

gh attestation verify goose-x86_64-unknown-linux-gnu.tar.bz2 -R block/goose

Risk: Zero breaking changes - attestations are additive metadata. Rollback is a simple revert.

Motivation

My setup-goose-action downloads goose binaries in CI/CD. Attestations enable cryptographic verification of provenance without manual checksum management.

---

Happy to open a PR if maintainers are interested. Can provide full implementation plan with detailed test strategy if helpful.

[nealmcb]

I want to voice strong support for this and other work to improve supply-chain protection for Goose. I had similar thoughts when I encountered the INSTALL.md with it's quick-and-dirty pattern of curl | bash or "download one-off .deb package, install with sudo". This is after all a tool which will often have tremendous leverage in installations with a lot of power, and environments which are poorly secured, despite the advice in SECURITY.md

I agree that actions/attest-build-provenance is a solid win and provides SLSA provenance in in-toto form signed via Sigstore/OIDC.

But I don't think it is an alternative to cosign. Build provenance attestations ≠ publisher signatures on the release artifacts.

I would suggest doing both, and also pushing the cryptographic protections deeper by considering signed git commits using offline keys, key management via Tuf, etc.

I hope the Linux Foundation infrastructure and best practices helps with all that.