fix: publish verifiable build provenance for releases#32
Merged
Conversation
A friend ran our installer past a due-diligence agent, which flagged it as risky: it couldn't find the source repo, checksums.txt offers no protection against a malicious publisher (the same release controls both the binary and the checksums), and the binary's behavior/telemetry were undisclosed in the script it read. Close the verifiable-trust gaps: - release.yml attests every release artifact with GitHub build provenance (Sigstore-signed, recorded in a public transparency log), verifiable with `gh attestation verify`. Stronger than checksums.txt: it ties each archive to this repo, commit, and workflow run. - analyze.sh links the source repo and discloses the privacy posture and how to verify what it downloads. - README documents provenance verification. Reputation/age and the inherent "trust an opaque binary" tradeoff can't be engineered away; this closes the parts that can be.
blimmer
commented
May 29, 2026
| - name: Attest build provenance | ||
| uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0 | ||
| with: | ||
| subject-checksums: dist-release/checksums.txt |
Contributor
Author
There was a problem hiding this comment.
We should also do this on PlanBridge
blimmer
pushed a commit
that referenced
this pull request
May 29, 2026
🤖 I have created a release *beep* *boop* --- ## [0.2.5](v0.2.4...v0.2.5) (2026-05-29) ### Bug Fixes * publish verifiable build provenance for releases ([#32](#32)) ([560aeee](560aeee)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: contextbridge-pr-automation[bot] <259134118+contextbridge-pr-automation[bot]@users.noreply.github.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.
Summary
A friend ran our installer (
bash -c "$(curl -fsSL https://patchwave.ai/analyze.sh)") past a due-diligence agent before trusting it. The agent flagged it as sketchier than it is — largely because it never found the source repo and judged only the wrapper script: it calledchecksums.txt"theater" (the same release controls both the binary and the checksums, so it guards against a corrupted download, not a malicious publisher), noted you're trusting an opaque compiled binary, and said the binary's data destination/telemetry were undisclosed in what it read.This closes the gaps that are actually closeable:
gh attestation verify <archive> --repo contextbridge/patchwave-analysis. This is the real answer to the "checksums are theater" point: it ties each archive to this repo, commit, and CI run, not just to a hash published next to it.analyze.shnow links the source, states the privacy posture (anonymous telemetry only;DO_NOT_TRACK=1; report stays local), and points to verification — so a reviewer reading just the script gets the full picture.What this deliberately does not fix: repo reputation/age, and the inherent tradeoff of running an opaque binary — those can be mitigated (provenance + readable source) but not engineered away.
Review focus
actions/attest-build-provenancewithsubject-checksums: dist-release/checksums.txt— this is GoReleaser's officially documented integration (GoReleaser has no native provenance generator; it delegates to GitHub's attest action). Considered GoReleaser's cosignsignsinstead and rejected it: cosign verification is clunkier and less recognizable thangh attestation verify. Note provenance is not retroactive — only releases cut after this merges will verify.Commits
177f80b— fix: publish verifiable build provenance for releases