Restore the SBOM predicate when re-attesting a release - #32
Merged
Conversation
The org transfer orphaned every attestation on v0.2.36 through v0.2.39. Each of those digests originally carried three predicates: SLSA build provenance, a CycloneDX SBOM, and GitHub's own in-toto release/v0.2 statement. This workflow restored one, so the four releases now carry provenance and nothing else, while the data room still describes all three. Adds the SBOM predicate, mirroring the step release.yml runs for a normal release, and extends the reproduction gate to cover it: the rebuilt SBOM must match the SBOM the release published, or the job attests nothing. The SBOM is deterministic (uuid v5 serial, no build timestamp), so a rebuild of the tagged source reproduces it byte for byte. Also skips any predicate the digest already carries. Re-signing a claim that is already on record adds noise, not evidence, and it would have left these four with a duplicate provenance. Two things this deliberately does not do. It does not emit an in-toto release/v0.2 predicate. That statement is issued by GitHub at publication time and signed by https://dotcom.releases.github.com, not by a workflow identity, and these releases are already published and immutable. A lookalike signed by Actions would be a different claim wearing the same predicate type. It does not and cannot make these four pass verification that pins --signer-workflow to release.yml at the tag. The provenance names attest-release.yml@refs/heads/main, because that is what built it. The difference is permanent and documented rather than papered over. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The org transfer orphaned every attestation on v0.2.36 through v0.2.39. Each of
those digests originally carried three predicates: SLSA build provenance, a
CycloneDX SBOM, and GitHub's own in-toto
release/v0.2statement. The recoveryworkflow restored one, so today each digest carries exactly one attestation
while
evidence/attestation-v0.2.38.txtin the data room still describes three.This adds the SBOM predicate to
attest-release.yml, mirroring the steprelease.ymlruns for a normal release, and extends the reproduction gate tocover it: the rebuilt SBOM must match the SBOM the release published, or the job
attests nothing. It also skips any predicate the digest already carries, so
re-dispatch does not leave duplicate provenance behind.
What this deliberately does not do
No synthesized in-toto
release/v0.2predicate. That statement is issued byGitHub at publication time and signed by
https://dotcom.releases.github.com(
O=GitHub, Inc., CN=Attester), not by any workflow identity. These releases arealready published and immutable, so the platform will not reissue it. Emitting a
lookalike from Actions would be a different claim wearing the same predicate type.
No fix for the signer identity. The surviving provenance on these four names
attest-release.yml@refs/heads/main, because that is what built it. Verificationthat pins
--signer-workflow .../release.yml --source-ref refs/tags/vXfails forthem and will keep failing. That is the honest result, and it is being documented
in the data room rather than disguised.
Practical consequence
publish-npm.ymlruns the strict form in its verify job, so an npm publish ofv0.2.36 through v0.2.39 would fail there. Nothing is blocked today: npm serves
0.2.41, attested natively, and only the newest version is ever published.
Verified before this change