Field Notes

concept

Reproducible builds

StatusStableUpdatedStands on4 sourcesSupportsnotes

A reproducible build is a software build process that produces a byte-identical output when given the same source code and build instructions, regardless of when or where the build runs. It converts the claim “this binary was built from this source” from an assertion by the publisher into a checkable claim by any independent party.

Why they matter

Ordinary code signing proves integrity in transit and continuity of publisher. It does not prove that a signed binary corresponds to the source a user can read. A compromised build machine, a malicious CI step, or a deliberately divergent private build all produce a validly signed binary that diverges from the public source, and the signature reveals none of it.

Reproducible builds close that gap. When builds are deterministic, an independent rebuilder can compile the same source and verify a byte-for-byte match with the published artifact. Source-to-binary correspondence is the property that reproducibility makes checkable.

Deployed use

The strongest deployed form combines reproducibility with developer signing: a rebuilder compiles from public source, fetches the developer’s own signed binary, and publishes it only if the two are identical apart from the signature block the rebuilder cannot produce. The result carries both continuity of publisher and verified correspondence to source.

Android app distribution trust models evaluates distribution channels on this axis. F-Droid is the channel organized around closing the gap, first by building from source, and increasingly by verifying developer-signed binaries against its own deterministic rebuild. By July 2026, 1,339 of 4,113 apps in F-Droid’s main repository — 32.6% — published a latest version signed by the developer’s own key after passing F-Droid’s rebuild comparison, up from roughly 21% at the end of 2025.

A rebuild check is only as good as its uptake. Where no independent party runs the comparison, reproducibility is a property the artifact has rather than a verification anyone performed, and the trust it was meant to remove moves to whoever asserts the build reproduced.

Determinism is not the binding constraint

Reproducibility presupposes Rebuildability: a build that cannot be executed at all today cannot be checked for determinism. The first empirical measurement of how that presupposition holds over a distribution’s history found the second property in far better shape than the first. Rebuilding 18,904 F-Droid app versions that had passed a reproducibility check when published, Nanni and colleagues completed 83.7% of the builds, and of those, 94% were still bitwise identical. Missing dependencies caused around 76% of the failures.

That asymmetry redirects where the effort belongs. Non-determinism is the problem reproducible-builds work was created to solve, and in this corpus it is largely solved; what erodes is the ability to reconstruct the build environment. The practical implications are archival rather than cryptographic: preserve source and transitive dependencies in a durable archive, and pin the exact toolchain and image a build used rather than leaving it to be inferred later.

Built on 4 sources (4 external).

Working out connections…