When a privacy app publishes its source code, many users assume that's sufficient to trust the binary they download. It isn't. The gap between source code and running software is a build pipeline — and that pipeline is exactly where sophisticated attackers insert themselves. Reproducible builds close that gap.

Open source software has a trust problem that open source alone doesn't solve. You can publish every line of code on GitHub and still distribute a binary that contains code nobody reviewed. The build system — the servers, scripts, compilers, and toolchains that turn source into executable — sits between the audited code and the running program.

Reproducible builds are a technique that lets anyone independently verify a binary was compiled from specific source code, without trusting the developer's build infrastructure. The property is simple to state and surprisingly difficult to achieve: given the same source code and build instructions, any two independent builds produce byte-for-byte identical output.

Why Build Pipelines Are Attack Targets

Ken Thompson's 1984 Turing Award lecture, "Reflections on Trusting Trust," articulated the fundamental problem: a compiler can be modified to insert backdoors into any program it compiles, including its own source. The attack is self-perpetuating and invisible in the source code. Thompson called this the "trusting trust" problem and concluded: "You can't trust code that you did not totally create yourself."

Modern supply chain attacks follow the same logic. The 2020 SolarWinds compromise inserted malicious code into the Orion build system — the distributed binaries contained backdoors that weren't in the source repository. The Xcode Ghost incident in 2015 involved a modified version of Apple's development toolchain distributed via unofficial channels; apps compiled with it contained hidden functionality. In neither case would auditing the source code have caught anything.

The trust problem: Open source proves that reviewed code exists. It does not prove the binary you downloaded was compiled from that code. A developer's build server, CI/CD pipeline, or signing key could all be compromised without any change to the publicly visible source repository. Reproducible builds let you check.

For privacy software specifically, this is a high-value target. An attacker who compromises the build pipeline of a secure messenger can distribute a backdoored version to millions of users while every public code audit comes back clean.

What Makes a Build Non-Reproducible

Most software builds are non-reproducible not because of malice, but because developers don't think about it. Common sources of non-determinism:

• Timestamps — compilers embed file modification times or build timestamps into binaries by default
• File system ordering — directory listings are not ordered consistently across systems; build tools that iterate over files produce different object ordering
• Locale and timezone — string sorting and date formatting vary by system locale
• Random seeds — some compilers randomize symbol ordering for security (ASLR) without preserving the seed
• Toolchain version differences — different compiler versions produce different output even from identical source
• Embedded paths — the absolute path of the build directory is often embedded in debug symbols

Achieving reproducibility requires explicitly controlling or eliminating all of these: fixing timestamps (often to the date of the last commit), using deterministic file ordering, specifying exact toolchain versions, and stripping or normalizing embedded paths.

Who Achieves It

The Tor Browser is the most prominent example in the privacy space. The Tor Project has shipped reproducible builds since 2013. Anyone can download the Tor Browser source, follow the published build instructions using the specified toolchain, and verify that the resulting binary matches what the Tor Project distributes — down to the SHA-256 hash. This is a meaningful security property: it means you can verify the binary without trusting Tor Project's build infrastructure.

Bitcoin Core has supported reproducible builds since 2019 via Guix-based bootstrapping. The project uses GNU Guix to build from a minimal, audited set of binary seeds, then bootstraps the entire toolchain from source. The result is verifiable at every stage. For software that controls financial assets, this level of rigor is warranted.

Debian Linux has been working toward reproducible builds since 2015. As of 2026, the vast majority of packages in Debian's archive are reproducible. The project maintains a public tracker at reproducible-builds.org that shows which packages pass and which don't.

Signal does not currently ship reproducible builds for its mobile apps. This is a known gap that the Signal community has raised. The Android APK can be rebuilt and compared, but the build environment reproducibility is not fully guaranteed. F-Droid, an alternative Android app store focused on free and open source software, builds apps from source in a clean environment and signs them independently of the original developers — a partial mitigation that shifts trust from the developer's pipeline to F-Droid's.

How to Verify in Practice

For software that supports reproducible builds, verification follows a consistent pattern:

1. Obtain the source code at the exact tagged version of the release you're verifying
2. Install the exact toolchain version specified in the build documentation
3. Run the build using the provided build script or container
4. Compare the SHA-256 (or SHA-512) hash of your output against the developer's published hash
5. Optionally: verify the developer's published hash is signed by a key you've verified via the web of trust or key transparency

The process is computationally intensive — rebuilding the Tor Browser or Bitcoin Core takes significant time and disk space. Most users won't do this. The value is that someone can, and that a large community of independent builders checking each release creates a strong deterrent against tampering.
— Reproducible Builds project documentation

Reproducibility and Key Transparency

Reproducible builds answer one question: does this binary match this source? They don't answer: did everyone get the same binary? A compromised distribution server could serve different binaries to different users — a targeted attack that reproducible builds alone don't detect.

This is where key transparency and binary transparency come in. Systems like binary transparency logs (analogous to Certificate Transparency for TLS) maintain an append-only, publicly auditable log of every binary release. Clients can verify that the binary they received is included in the log, and that the log is consistent across all observers.

The combination of reproducible builds (anyone can verify source-to-binary integrity) and binary transparency (anyone can verify they received the same binary as everyone else) closes the loop on software supply chain verification. Both properties together are necessary; neither is sufficient alone.

Status Across Privacy Software

The Standard Worth Demanding

For any software that handles your private communications, financial assets, or encryption keys, reproducible builds should be a minimum expectation — not an advanced feature. The Tor Project and Bitcoin Core demonstrate it's achievable for real-world, complex software. The absence of reproducible builds doesn't make software untrustworthy, but it does mean you're placing unverifiable trust in a build pipeline you can't inspect.

For privacy-conscious users evaluating tools, asking "are the builds reproducible?" is a legitimate and important question. For developers of privacy software, achieving it is worth the engineering investment. The Reproducible Builds project maintains tooling, documentation, and a community that makes the path clearer than it was a decade ago.

Originally published at havenmessenger.com