Add SLSA build provenance attestations to release workflows

[tlongwell-block]

Add actions/attest-build-provenance to release, canary, nightly, and Docker workflows. Every CLI binary, desktop bundle, Linux package, and container image now gets a signed provenance attestation via Sigstore.

Users can verify any artifact with:
gh attestation verify --repo block/goose

Changes:

• release.yml: attestations:write permission + attestation step
• canary.yml: explicit permissions block + attestation step
• publish-docker.yml: id-token:write, attestations:write, capture image digest, attest with push-to-registry

Closes #5994

[tlongwell-block]

/goose

[github-actions]

PR #7097 Review: Add SLSA build provenance attestations to release workflows

Summary: This PR adds SLSA (Supply Chain Levels for Software Artifacts) build provenance attestations to all release workflows using GitHub's actions/attest-build-provenance action with Sigstore OIDC signing. This is a well-implemented security enhancement that allows users to cryptographically verify the integrity and origin of release artifacts.

✅ Highlights

1. Correct permission setup: All workflows correctly add both id-token: write (for Sigstore OIDC signing) and attestations: write (for storing attestations) at the appropriate scope levels.

2. Proper action pinning: The actions/attest-build-provenance@96278af6caaf10aea03fd8d33a09a777ca52d62f # v3.2.0 action is pinned to a specific SHA with version comment - this is security best practice for supply chain integrity.

3. Docker attestation done right: The Docker image attestation correctly:

   • Uses the digest reference (${{ steps.docker-push.outputs.digest }}) rather than a mutable tag
   • Sets push-to-registry: true to attach the attestation to the registry
   • References the correct repository name

4. Consistent subject-path patterns: The subject-path patterns correctly match the existing artifacts patterns in each workflow:

   • release.yml: includes goose-*.zip and *.flatpak
   • canary.yml/nightly.yml: includes **/*.flatpak (no goose-*.zip)

   These differences are pre-existing in the artifact definitions and not introduced by this PR.

5. Good placement: The attestation step is placed after artifact download but before the release step, ensuring all artifacts are attested before publication.

🟢 Suggestions

1. Consider consolidating artifact patterns (out of scope for this PR): The differences in artifact patterns between release.yml and canary.yml/nightly.yml could be worth investigating in a follow-up - e.g., why does only the versioned release include goose-*.zip? This is pre-existing technical debt, not introduced by this PR.

Overall Assessment

Approve - This is a clean, well-implemented security enhancement. The PR correctly applies the attestation action across all four release workflows with proper permissions, action pinning, and artifact patterns that match the existing release configurations.

---

Review generated by goose

[tlongwell-block]

/goose

[github-actions]

Summary: This PR correctly adds SLSA build provenance attestations to the release, canary, and Docker workflows using the actions/attest-build-provenance action. The implementation is well-structured with properly pinned actions and minimal permission additions. One minor documentation issue in the PR description.

🟡 Warnings

1. PR description inaccuracy - The PR body mentions modifying nightly.yml, but this file doesn't exist and no such changes are in the diff:

   "nightly.yml: explicit permissions block + attestation step"

   Recommend updating the PR description to remove the nightly.yml reference to avoid confusion.

🟢 Suggestions

1. Consider attestation for install script (.github/workflows/canary.yml, .github/workflows/release.yml) - The download_cli.sh script is included in subject-path. While not harmful, shell scripts are typically lower-value attestation targets since users often pipe them directly (curl | sh). Consider whether this adds meaningful security value or could be omitted for simplicity.

✅ Highlights

1. Properly pinned action with verified SHA - The actions/attest-build-provenance action is correctly pinned to commit SHA 96278af6caaf10aea03fd8d33a09a777ca52d62f with a version comment (# v3.2.0). I verified this SHA matches the v3.2.0 tag.

2. Minimal permission scope - Permissions are added at the appropriate level:

   • id-token: write for Sigstore OIDC signing
   • attestations: write for creating attestations
   • Job-level permissions in release.yml keep the blast radius minimal

3. Consistent artifact patterns - The subject-path patterns in each workflow correctly match the existing artifacts: patterns in the release actions. For example, release.yml includes goose-*.zip for Windows CLI builds while canary.yml doesn't (matching their respective existing artifact lists).

4. Docker attestation done correctly - The Docker workflow properly:

   • Adds an id: docker-push to capture the build output
   • Uses subject-digest: ${{ steps.docker-push.outputs.digest }} to reference the exact image
   • Sets push-to-registry: true to push attestations to the registry

---

Review generated by goose