From 3f3c31c815671ec43c7a83f8eb200e5522cf42f5 Mon Sep 17 00:00:00 2001 From: HeapSmasher <98077186+las7@users.noreply.github.com> Date: Sat, 15 Aug 2026 00:29:41 +0000 Subject: [PATCH] Attest build provenance, which needs no key of ours at all MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A Developer ID signature says Reachpad signed this. It says nothing about what was signed or where it came from, and it rests on a private key somebody could steal — which is the failure mode the whole signing setup is built to survive rather than prevent. Build provenance is the other half, and it is the half Apple cannot give us: a signed statement that these exact bytes came out of this workflow, at this commit, in this repo, with the signing identity a short-lived OIDC credential minted for the run and the record in a public transparency log. There is no long-lived secret to steal, so there is nothing to rotate and nothing to revoke. It also covers the Linux tarballs, which have no Gatekeeper and would therefore never have been signed by anything. gh attestation verify reachpad-.tar.gz --repo Reachpad/reachpad-cli Free on public repositories. The release body and the README both say how to run it, because a verification nobody is told about is one nobody performs. Greentree-Change-Id: 0346a742daa0ff4ff23182aa1f152686 --- .github/workflows/release.yml | 35 +++++++++++++++++++++++++++++++++++ README.md | 12 ++++++++++++ 2 files changed, 47 insertions(+) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index b3a9903..f304bc8 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -204,12 +204,36 @@ jobs: publish: needs: build runs-on: ubuntu-latest + permissions: + contents: write + id-token: write # the OIDC claim the attestation is signed against + attestations: write steps: - uses: actions/download-artifact@v4 with: merge-multiple: true - name: combined checksum file run: cat *.sha256 > SHA256SUMS + + # Build provenance: a signed, publicly verifiable statement that these + # exact bytes came out of THIS workflow, at THIS commit, in THIS repo. + # + # This is the half of the problem Apple cannot solve for us. A Developer + # ID signature says "Reachpad signed this"; it says nothing about what + # was signed or where it came from, and it depends on a private key that + # somebody could steal. This depends on no key at all — the signing + # identity is a short-lived OIDC credential GitHub mints for this run, + # and the record goes into a public transparency log, so a forged + # attestation would have to be forged in public. + # + # It also covers Linux, which has no Gatekeeper and therefore no reason + # anyone would ever have signed those tarballs. + # + # gh attestation verify reachpad-.tar.gz --repo Reachpad/reachpad-cli + - name: attest build provenance + uses: actions/attest-build-provenance@v4 + with: + subject-path: "*.tar.gz" # The body carries the macOS quarantine note on purpose. Downloading a # tarball from THIS page in a browser is the one install path that # stamps com.apple.quarantine, and until the binaries are notarized it @@ -252,6 +276,17 @@ jobs: Verify the checksum first, as above; that is the check the signature would otherwise be doing for you. + ## Verifying where these came from + + Every tarball carries a signed build-provenance attestation: proof + that these exact bytes came out of this repository's release + workflow, at the commit this tag names. It needs no key of ours — + the record lives in a public transparency log. + + ```sh + gh attestation verify reachpad-.tar.gz --repo Reachpad/reachpad-cli + ``` + # The same binaries, on npm. Separate job so a registry outage cannot lose # the GitHub release, and `needs: publish` so npm never advertises a version # whose release page does not exist yet. diff --git a/README.md b/README.md index f3c8dcc..6354edc 100644 --- a/README.md +++ b/README.md @@ -92,6 +92,18 @@ cargo build --release -p reach ./target/release/reachpad --version ``` +Every release tarball also carries a signed build-provenance attestation, so +the chain is checkable without trusting us: + +```sh +gh attestation verify reachpad-.tar.gz --repo Reachpad/reachpad-cli +``` + +That proves the bytes came out of this repository's release workflow at the +commit the tag names. It rests on no key of ours — the signing identity is a +short-lived credential minted for that one workflow run, and the record is in +a public transparency log. + The snapshot is synced from a private monorepo on every release, so file an issue rather than a PR for changes; a PR here would be overwritten by the next sync (the sync script and its header in `Cargo.toml` say the same).