ci(release): attest build provenance for release artifacts#11441
Conversation
Generate Sigstore-backed SLSA build provenance for the platform tarballs and zips produced by `pn copy-artifacts` via actions/attest-build-provenance, so users can verify with `gh attestation verify` that the binaries attached to a GitHub release came from this repository's release workflow rather than from a manual upload. This complements the release attestation that GitHub auto-generates for Releases (predicate `https://in-toto.io/attestation/release/v0.2`), which only proves what files were attached to a tag, not how they were built. The new attestation uses `https://slsa.dev/provenance/v1` and binds each artifact's digest to the workflow_ref, commit SHA, and runner identity. The `pn release` step already publishes npm tarballs with provenance, so this closes the same gap on the GitHub Release side.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe release workflow is extended to support build provenance attestation. A new permission ChangesBuild Provenance Attestation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
There was a problem hiding this comment.
Pull request overview
This PR enhances the release workflow by generating Sigstore-backed SLSA v1.0 build provenance attestations for the per-platform binary archives produced during pn copy-artifacts, enabling downstream users to verify that GitHub Release assets were built by this repository’s release workflow.
Changes:
- Add
attestations: writepermission to thereleasejob to allow publishing provenance attestations. - Add an
actions/attest-build-provenancestep to attest all files produced underdist/*before uploading them to the GitHub Release.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Generate Sigstore-backed SLSA build provenance for the platform tarballs and zips produced by `pn copy-artifacts` via actions/attest-build-provenance, so users can verify with `gh attestation verify` that the binaries attached to a GitHub release came from this repository's release workflow rather than from a manual upload. This complements the release attestation that GitHub auto-generates for Releases (predicate `https://in-toto.io/attestation/release/v0.2`), which only proves what files were attached to a tag, not how they were built. The new attestation uses `https://slsa.dev/provenance/v1` and binds each artifact's digest to the workflow_ref, commit SHA, and runner identity. The `pn release` step already publishes npm tarballs with provenance, so this closes the same gap on the GitHub Release side.
Summary
Generate Sigstore-backed SLSA build provenance for the per-platform binary archives produced by
pn copy-artifacts, usingactions/attest-build-provenance. Users can then verify withgh attestation verifythat the binaries attached to a GitHub Release were actually produced by this repo's release workflow rather than uploaded manually.Why this is not redundant with the existing release attestation
GitHub already auto-generates a release attestation (predicate type
https://in-toto.io/attestation/release/v0.2) for every release in this repo, e.g. forv11.0.4. That attestation only proves which file digests were attached to a tag in this repo. It does not prove how those files were built — anyone with release-write permission (a leaked PAT, a malicious workflow) can attach arbitrary binaries to a release, and GitHub will dutifully sign a release attestation for them.The new build-provenance attestation uses predicate type
https://slsa.dev/provenance/v1and binds each artifact's digest to:.github/workflows/release.yml) and commit SHA that built it,The two attestations are complementary, not duplicates: release proves "where the file was hosted," build provenance proves "how the file was built."
The
pn releasestep already publishes the npm tarballs with--provenance, so this closes the same gap on the GitHub Release side.Implementation notes
attestations: writepermission added to thereleasejob alongside the existingid-token: write(already present for npm OIDC).Copy Artifacts(sodist/*exists) and beforeRelease(so the digests being signed match what gets uploaded).v4.1.0SHA to match the convention used by the other actions in this workflow.Test plan
gh attestation verify <artifact> --repo pnpm/pnpm --predicate-type https://slsa.dev/provenance/v1succeeds for eachpnpm-*archive andsource-maps.tgz.slsa.dev/provenance/v1andin-toto.io/attestation/release/v0.2) are visible in the release's attestations API.Summary by CodeRabbit