Repository navigation
fix(release): attest and attach the SBOM before the immutable Release exists - #99
Conversation
… exists Releases here are immutable, so publishing one freezes its assets. The publish job created the Release with SHA256SUMS, then uploaded the SBOM (HTTP 422: Cannot upload assets to an immutable release), and the attestation step behind it never ran. v0.4.3 through v0.4.6 carry SHA256SUMS only and have no provenance attestation, although the workflow told users to verify one. Generate the SBOM and attest SHA256SUMS first, then create the Release with every asset in the one call that publishes it. A re-run against an existing Release now leaves it alone instead of trying to upload to it, and still attests.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
get-resq-software | 5111a3d | Oct 03 2026, 10:08 PM |
github-actions
Bot
added
C-Bug
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 41 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
I have audited the changes in this pull request and found no security vulnerabilities, logic bugs, or performance issues. The workflow is well-written and follows security best practices. Good job!
|
2 participants
Summary
The v0.4.6 release run failed at publish release:
Releases in this repo are immutable: publishing one freezes its assets. The publish job created the Release with
SHA256SUMS, then tried to upload the SBOM, which GitHub refuses. Attest build provenance came after it and was skipped. This isn't specific to v0.4.6:install.shSHA256SUMSSHA256SUMSSHA256SUMSSHA256SUMSMeanwhile the workflow comment tells users to
gh attestation verify install.sh --repo resq-software/dev.Change
The publish job now runs:
SHA256SUMSfrom the pin set.SHA256SUMSandsbom.spdx.jsonin the one call that publishes it.The separate "Attach the SBOM" step is removed. On a re-run where the Release already exists, the job no longer tries to upload to it, because an immutable Release can't change. It logs the assets the Release carries and exits 0, and since attestation now runs first, a re-run still attests.
This changes only
release.ymland doesn't release anything by itself, because the trigger is aVERSIONchange.What was not affected
get.resq.softwareserves bytes pinned by digest inworker/src/index.ts(#98 for v0.4.6). I checked all seven v0.4.6 pins against the files at thev0.4.6commit (9bac29b) and they match. Only the SBOM and the provenance attestation were missing; the installers themselves were correct.Test plan
release.ymlSHA256SUMS+sbom.spdx.json, andgh attestation verify install.sh --repo resq-software/devpassesOpen question
Should v0.4.6 get a provenance attestation after the fact? After this merges, a
workflow_dispatchre-run would attest v0.4.6'sSHA256SUMS. The provenance would name the commit the re-run ran at, not9bac29b. The installer bytes are identical at both, but it is a backfill rather than the original build's record. The alternative is to let v0.4.7 be the first attested release.