Reproducible Builds

Containment Chamber produces bit-for-bit identical binaries and Docker images across builds. Given the same source code and toolchain, any two builds of the same commit produce the same SHA256 digest — for both the binary and the container image.

This means you can independently verify that a published release was built from the claimed source code, with no hidden modifications.

Why It Matters

A remote signer holds validator private keys. If a compromised build pipeline injected malicious code into the binary, validators would unknowingly sign with tampered software. Reproducible builds make this detectable: anyone can rebuild from source and compare the result against the published artifact.

How It Works

The build pipeline has two stages. The Dockerfile compiles the binary, then crane assembles the production Docker image.

Dockerfile compiles inside rust:1.94-alpine3.23 (pinned by digest) with reproducibility flags and cargo-auditable for embedded dependency SBOM. The binary is extracted from the container.

crane builds the OCI image without Docker — no layer timestamps, no random metadata. Same inputs always produce the same image digest.

Reproducibility Flags

Every build applies these flags to eliminate non-determinism:

Flag	What it eliminates
SOURCE_DATE_EPOCH	Non-deterministic build timestamps
--build-id=none	Random ELF build ID
-C metadata=''	Path-dependent symbol name hashes
--remap-path-prefix	Build machine filesystem paths
CARGO_INCREMENTAL=0	Non-deterministic incremental artifacts
LC_ALL=C / TZ=UTC	Locale and timezone-dependent output
--locked	Dependency version drift

Verifying a Release

Verify binary provenance (SLSA attestation)

Every release binary has a SLSA provenance attestation proving it was built by the CI pipeline:

gh release download v1.2.3 -p 'containment-chamber-linux-amd64'
gh attestation verify ./containment-chamber-linux-amd64 \
  --owner unforeseen-consequences

Verify Docker image signature (cosign)

Every Docker image is signed with Sigstore keyless signing:

cosign verify \
  --certificate-identity-regexp \
    'https://github.com/unforeseen-consequences/containment-chamber/.github/workflows/release.yml' \
  --certificate-oidc-issuer \
    'https://token.actions.githubusercontent.com' \
  ghcr.io/unforeseen-consequences/containment-chamber:v1.2.3

Rebuild from source and compare

The strongest verification — rebuild the binary yourself and compare SHA256:

1. Check out the release tag:

   git checkout v1.2.3

2. Compute the build metadata:

   SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
   GIT_SHA=$(git rev-parse HEAD)
   GIT_DESCRIBE=$(git describe --always)

3. Build inside Docker (same environment as CI):

   docker build \
     --build-arg SOURCE_DATE_EPOCH="$SOURCE_DATE_EPOCH" \
     --build-arg VERGEN_GIT_SHA="$GIT_SHA" \
     --build-arg VERGEN_GIT_DESCRIBE="$GIT_DESCRIBE" \
     -t cc-verify . --no-cache

4. Extract the binary:

   docker create --name cc-extract cc-verify
   docker cp cc-extract:/containment-chamber ./my-binary
   docker rm cc-extract

5. Download the release binary and compare:

   gh release download v1.2.3 -p 'containment-chamber-linux-amd64'
   sha256sum my-binary containment-chamber-linux-amd64

If the hashes match, the published binary was built from the tagged source with no modifications.

CI Pipeline

Every push to main builds a reproducible binary and publishes a signed Docker image. On tags, a verification step builds twice and blocks the release if the binaries differ.

Local Verification

Run the full verification locally (builds twice, compares binary SHA256 and crane image digest):

just verify-reproducible

Note

This takes ~15 minutes (two full Docker builds with cache prune between them). Requires Docker and crane (mise install crane).

Embedded SBOM

Every binary includes a cargo-auditable dependency SBOM in the .dep-v0 ELF section. Container vulnerability scanners (Trivy, Grype, Syft) can extract and scan it:

cargo audit bin containment-chamber-linux-amd64