Verifiable and attested Chainweb binary releases

[itshoney27]

Summary

I would like to contribute a security-hardening PR that makes Chainweb binary releases independently verifiable from source commit to published artifact.

Current trust gap

The build workflow uploads a compiled archive to S3. The release workflow later downloads and extracts that archive, but currently does not verify a trusted provenance attestation before extraction.

The release workflow also permits release_sha to differ from the workflow's own github.sha. Simply adding an attestation to the final repackaged archive could therefore identify the packaging workflow commit rather than the source commit that built the binary.

This is not a claim that the current releases have been compromised. The objective is to provide cryptographic source-to-binary verification for miners, exchanges and node operators.

Proposed first PR

Scope the first PR to the Ubuntu binary release path in chainweb-node:

1. Build the distributable archive from an exact full source commit.
2. Generate GitHub/Sigstore build provenance using actions/attest.
3. Verify repository, workflow, source commit and trusted ref before the archive is extracted or released.
4. Publish SHA256SUMS with the release.
5. Pin release-critical GitHub Actions and reusable workflows to full commit SHAs.
6. Validate release inputs and avoid direct workflow-input interpolation in shell commands.
7. Ensure fork and pull-request builds cannot publish packages or access release credentials.
8. Document the operator verification command.

Suggested release design

The strongest design would build, package, attest and publish the same bytes from a protected version tag.

A smaller alternative would retain the manual release workflow but require:

• release_sha == github.sha;
• verification of the attested build archive before extraction;
• deterministic repackaging;
• a second attestation for the final release archive.

Out of scope for the first PR

• DockerHub release changes
• SBOM generation
• Reproducible GHC compilation
• Consensus or protocol changes

These can be separate follow-up PRs.

Questions for maintainers

1. Would you prefer a protected-tag build-and-release workflow or a hardened version of the current manual workflow?
2. Is it acceptable to remove arbitrary release_sha, or require it to equal github.sha?
3. Should the release publish the exact attested build archive without repackaging?

I can submit the implementation as a draft PR after confirming the preferred approach.

[CryptoPascal31]

Anyway, the node workflow would require a deep cleaning, and update.

Why not just signing the binaries with GPG keys ?

We can propose a double/triple signatures:

• One from the workflow
• One/Two with personal maintainers keys.

[itshoney27]

Thanks Pascal. I agree that cleaning and updating the existing release workflow should come first.

Would the following two-stage approach make sense?

1. The first PR would clean and harden the release workflow: pin third-party GitHub Actions, restrict workflow permissions, ensure binaries are built from the expected source commit, generate SHA256SUMS, and publish GitHub Artifact Attestations/Sigstore-backed provenance.

2. A second PR could add detached GPG signatures from maintainers after the project agrees on the authorized signers and minimum number of required signatures—for example, signatures from at least two maintainers.

The maintainers’ private GPG keys would remain outside GitHub Actions. Automated provenance would identify the workflow and commit that produced the binaries, while the independent maintainer signatures would approve the release.

If this direction works for the maintainers, I can begin by auditing the current workflow and preparing a small draft PR for the first stage.