言語パッケージマネージャーにおける再現可能なビルド

You download a package from a registry and the registry says it was built from a particular git commit, but the tarball or wheel or crate you received is an opaque artifact that someone built on their machine and uploaded. Reproducible builds let you check by rebuilding from source yourself and comparing, and if you get the same bytes, the artifact is what it claims to be. Making this work requires controlling both the build environment and the provenance of artifacts, and most language package managers historically controlled neither.

The Reproducible Builds project has been working on this since 2013, when Lunar (Jérémy Bobbio) organized a session at DebConf13 and began patching Debian’s build tooling. The Snowden disclosures had made software trust an urgent concern, Bitcoin’s Gitian builder had shown the approach was viable for a single project, and the Tor Project had begun producing deterministic builds of Tor Browser. Lunar wanted to apply the same thinking to an entire operating system.

The first mass rebuild of Debian packages in September 2013 found that 24% were reproducible, and by January 2014, after fixing the lowest-hanging fruit in dpkg and common build helpers, that jumped to 67%. Today Debian’s testing infrastructure shows around 96% of packages in trixie building reproducibly under controlled conditions, while reproduce.debian.net runs a stricter test by rebuilding the actual binaries that ftp.debian.org distributes rather than clean-room test builds.

The project grew into a cross-distribution effort as Arch Linux, NixOS, GNU Guix, FreeBSD, and others joined over the following years. Summits have been held most years since 2015, most recently in Vienna in October 2025. Chris Lamb, who served as Debian Project Leader from 2017 to 2019, co-authored an IEEE Software paper on the project that won Best Paper for 2022. Lunar passed away in November 2024. The project’s weekly reports, published continuously since 2015, give a sense of the scale of work involved: each one lists patches sent to individual upstream packages fixing timestamps, file ordering, path embedding, locale sensitivity, one package at a time, hundreds of packages a year. Getting from 24% to 96% was not a single architectural fix but a decade of this kind of janitorial patching across the entire Debian archive.

How verification works

You build the same source twice in different environments and compare the output, and if the bytes match, nobody tampered with the artifact between source and distribution. In practice this requires recording everything about the build environment, which Debian does with .buildinfo

When hashes don’t match, diffoscope is how you find out why. Originally written by Lunar as debbindiff

The project also maintains strip-nondeterminism

What makes builds non-reproducible

Benedetti et al. tested 4,000 packages from each of six ecosystems using reprotest

The dominant cause across all three failing ecosystems was timestamps embedded in the package archive, responsible for 97.1% of RubyGems failures, 92.4% of Maven failures, and 87.7% of PyPI failures. The standard fix is SOURCE_DATE_EPOCH

Most of this turned out to be fixable with infrastructure changes rather than per-package work. Simply configuring SOURCE_DATE_EPOCH

os.path.expanduser

File ordering causes similar problems because readdir()

/home/alice/project

/home/bob/project

Since Go 1.21 in August 2023, the toolchain produces bit-for-bit identical output regardless of the host OS, architecture, or build time, after Russ Cox’s team eliminated ten distinct sources of nondeterminism including map iteration order, embedded source paths, file metadata in archives, and ARM floating-point mode defaults.

Go runs nightly verification at go.dev/rebuild using gorebuild

Maven’s official guide documents the steps: set project.build.outputTimestamp

mvn clean verify artifact:compare

The timestamp only works if every plugin in the chain respects it, though, and many third-party plugins don’t. Different JDK versions produce different bytecode, ZIP entry ordering varies by implementation, and Maven builds are assembled from dozens of plugins that each introduce their own potential nondeterminism. Researchers built Chains-Rebuild to canonicalize six root causes of Java build unreproducibility, which gives a sense of how many separate things can go wrong in a single build system.

Rust’s RFC 3127 introduced trim-paths

/home/alice/.cargo/registry/src/crates.io-abc123/serde-1.0.200/src/lib.rs

serde-1.0.200/src/lib.rs

Procedural macros and build scripts (build.rs

The Benedetti et al. study found only 12.2% of PyPI packages reproducible out of the box, and the split came down to build backend: packages using flit

PyPI has also moved further than most registries on attestations through PEP 740, shipped in October 2024, which adds support for Sigstore-signed digital attestations uploaded alongside packages. These link each artifact to the OIDC identity that produced it, so combined with trusted publishing, PyPI can record that a package was built in a specific CI workflow from a specific commit with a cryptographic signature binding artifact to source.

RubyGems 3.6.7 made the gem building process more reproducible by default, setting a default SOURCE_DATE_EPOCH

The npm registry accepts arbitrary tarballs with no connection to source, no build provenance, and no way to independently rebuild a package and compare it against what’s published. package-lock.json

Homebrew distributes prebuilt binaries called bottles, built on GitHub Actions and hosted as GitHub release artifacts. The project has a reproducible builds page documenting the mechanisms available to formula authors: SOURCE_DATE_EPOCH

@@HOMEBREW_PREFIX@@

Utils::Gzip.compress

Since Homebrew 4.3.0 in May 2024, every bottle comes with a Sigstore-backed attestation linking it to the specific GitHub Actions workflow that built it, meeting SLSA Build Level 2 requirements. Users can verify attestations by setting HOMEBREW_VERIFY_ATTESTATIONS=1

Trusted publishing

Traditionally a maintainer authenticates with an API token, builds on their laptop, and uploads. Trusted publishing replaces that with OIDC tokens from CI so that the registry knows the package was built by a specific GitHub Actions workflow in a specific repository, not just uploaded by someone who had the right credentials.

PyPI launched trusted publishing in April 2023, built by Trail of Bits and funded by Google’s Open Source Security Team. RubyGems.org followed in December 2023, npm shipped provenance attestations via Sigstore in 2023 and full trusted publishing in July 2025, crates.io launched in July 2025, and NuGet followed in September 2025. Over 25% of PyPI uploads now use it.

Once provenance tells you that a package was built from commit abc123

github.com/foo/bar

Google’s OSS Rebuild

OSS Rebuild, announced by Google’s Open Source Security Team in July 2025, takes a pragmatic approach to the fact that most builds aren’t bit-for-bit reproducible yet by rebuilding packages from source and performing semantic comparison, normalizing known instabilities like timestamps and file ordering before checking whether the meaningful content matches.

At launch it covered thousands of packages across PyPI, npm, and crates.io, using automation and heuristics to infer build definitions from published metadata, rebuilding in containers, and publishing SLSA Level 3 provenance attestations signed via Sigstore. The stabilize

Matthew Suozzo’s FOSDEM 2026 talk pushed beyond pure reproducibility into build observability, adding a network proxy for detecting hidden remote dependencies and eBPF-based build tracing to answer not just whether a build can be reproduced but what the build is actually doing at runtime, which is useful independently of whether the output happens to be deterministic.

Where things stand

Language package managers are years behind Linux distributions on reproducible builds because Debian controls its build infrastructure and can mandate changes to that environment, while language registries accept uploads from anywhere and historically had no way to know how an artifact was produced. Trusted publishing is shifting that by moving builds from laptops into CI where the registry has visibility into the process, and combined with build provenance and SLSA attestations, this creates conditions where independent verification becomes possible even when the build tooling itself hasn’t caught up. Go got there by making the compiler deterministic, which is the cleanest solution but requires controlling the entire toolchain from the start.