Skip to content

Reproducibility

Jump to bottom
Dan Riddell edited this page Sep 13, 2026 · 2 revisions

Reproducibility

Deterministic by construction. Reproducibility isn't a flag you enable. It's the only mode, and every knob — -trimpath, commit-derived timestamps, sorted archive entries, zeroed gzip headers — is set correctly by default.

Everything interesting downstream depends on it:

  • verify can rebuild a published release and compare it, because the rebuild produces the same bytes.
  • A re-run of release can ask "is this already uploaded and correct?" and recompute the answer from content, rather than trusting bookkeeping.
  • A container image digest is reproducible for the same reason the archives are.
  • The CycloneDX SBOM is byte-identical between runs, because its timestamp is the commit time and its serial number is derived from the module, version and commit rather than generated fresh. See Publishing.

How it is proven

The reproducibility suite is the project's go/no-go gate, and it runs on every push:

  • Same machine. The same commit built twice on one host, varying source directory, work directory, TMPDIR, wall clock and build cache.
  • Across machines. Built on Linux, macOS and Windows runners and compared byte for byte.

The Go toolchain is pinned to an exact patch release rather than stable, in both the release and reproducibility workflows. Compiler and linker output can legitimately differ between Go versions, so version skew between two runners would look like a reproducibility failure. The toolchain is a build input, and the release manifest records it for the same reason.

verify

$ letsgo verify v1.3.0

  ✓ fetched manifest from release
  ✓ rebuilt 5/5 targets at commit 9f2ab1c
  ✓ all digests match published assets
  ✓ dependency graph matches recorded go.sum
  ✓ provenance attestation valid (github-actions, danielriddell21/foo)

  v1.3.0 verified

Anyone can run it, on hardware you don't control. That is the whole point: a claim only you can check is not much of a claim.

Provenance

Releases carry an OIDC provenance attestation, signed with a short-lived identity minted for the run. There is no key to store and none to rotate. What it attests to is the workflow, repository and commit that produced the artifact — which is the one thing rebuilding cannot establish.

Clone this wiki locally