Reproducible Builds: Why You Shouldn't Have to Trust Our Binaries

Every security conversation eventually arrives at the same question: who do you trust? For software, the historical answer has been: whoever built the binaries. That is a remarkable amount of trust to extend to machines you will never see.

A binary, whether it is a kernel, a desktop app, or a package in a repository, is a black box unless it was produced in a way anyone can reconstruct. Compromise could come from the source repository, from the build machines, or from the toolchain itself. The usual options are to take the vendor’s word or to spend weeks pulling the artifact apart.

Reproducible builds offer a third path.

What reproducibility gives you

A build is reproducible when feeding the same source through the same toolchain in the same environment produces byte-for-byte identical output, across machines, across people, and across time.

When that holds, something useful emerges: anyone can independently verify our releases without trusting us.

• Independent researchers can recompile our published source and compare checksums with the official artifacts.
• Auditors can confirm that a release matches the code they reviewed, with no hidden dependencies or last-minute modifications.
• Even a compromised build server stops being a silent threat. A tampered artifact is caught the moment anyone rebuilds from source and compares the hashes.

What it actually takes

Reproducibility is more a discipline than a technology. In practice it means:

• Normalizing everything ambient. Timestamps, embedded paths, locale settings, and file ordering all have to be pinned or stripped.
• Deterministic environments. Every build runs in an isolated, pinned container, so “same source” genuinely includes “same environment”.
• Stable tooling. Build flags, tool versions, and hardening options are fixed parts of the recipe, not footnotes.
• Hardened output. A reproducible build of a fragile binary is still fragile, so the toolchain applies the full stack of exploitation mitigations (stack protection, PIE, fortify-source, and friends) by default.

Where it stops

Reproducibility does not prove that the source itself is trustworthy. A reproducible build of a malicious codebase is still a malicious codebase. That is why the other half of the practice has to be source review and consistent verification of contributors.

What reproducibility does is eliminate an entire class of unverifiable claims. When an organization tells you “here is the exact build of our operating system”, you can check.

What it means for Citadel

For an operating system designed to resist sophisticated adversaries, reproducibility is not a nice-to-have. The base of Citadel is built this way from the first byte: every update is atomic, signed, and reproducible from public sources. If you do not want to trust our binaries, you do not have to. Build them yourself, or wait for the independent researchers who do.

Later posts will walk through the actual build pipeline: the containers, the pins, and how a checksum ends up on the release page.