Reproducible builds are a supply chain argument

Open source tells you what the source code says. It does not tell you that the binary on your device was built from it. Those are different claims, and the gap between them is where the last decade’s most effective attacks have lived — not in the code everyone can read, but in the machinery between that code and the artefact people actually run.

The gap nobody looks at

Between a public repository and a running system there is a build machine, a toolchain, a set of dependencies pulled at build time, a signing key and a distribution channel. Every one of those is a place where the artefact can differ from the source, and almost none of them are audited by the people relying on the result.

The uncomfortable part is that this is not hypothetical. Compromised build infrastructure and poisoned dependencies are among the most effective attacks there are, precisely because they inherit all the trust that the open source project earned.

What reproducibility actually claims

A build is reproducible when the same source, with the same declared inputs, produces bit-identical output for anyone who runs it.

That sounds academic until you notice what it enables: independent verification. If three parties build the image and get the same hash as the published artefact, then the published artefact is what the source says it is. Nobody has to trust the build machine, because the build machine’s output can be checked by anyone with the source and a computer.

It converts “trust us” into “check us”, which is the only durable form of trust in infrastructure.

Why it is hard

Because software is full of accidental non-determinism, and every bit of it has to be found.

Timestamps embedded in archives and binaries. Build paths compiled into debug information. File ordering that depends on the filesystem. Locale and timezone leaking into generated text. Parallel builds that interleave differently each run. Version numbers derived from the moment of building rather than from the source.

None of these are hard individually. There are a lot of them, and they hide until you compare two builds byte by byte — which is exactly why the discipline has to be built in from the start rather than retrofitted.

What it buys a small project

The argument is usually made in terms of nation-state attackers, which makes it sound like somebody else’s problem. For a small project the everyday benefits are more mundane and more useful.

Debugging. “The build machine had a different library version” stops being a possible explanation, which removes a whole category of unreproducible bug.

Trust without headcount. A small team cannot ask anyone to trust its infrastructure. It can publish a definition and a hash and invite people to check — and that is a claim a small team can actually back.

Auditability. A regulated customer asking what is running on a device gets an image definition, a hash and a way to verify it themselves, instead of a letter of assurance.

A real fork. Open source that cannot be rebuilt independently is a read-only licence. Reproducibility is what makes the right to fork meaningful.

What we are committing to

The image definition public, the build pipeline public, artefacts signed, hashes published, and the build reproducible so anyone can confirm the two match.

Not because someone is coming for a pre-launch Linux distribution, but because the claims this project makes — minimal, hardened, sovereign — are all claims about what is not in the image. The only honest way to make that kind of claim is to let people check it themselves.