Two organisations rebuild the same package to identical digests — what does that prove that one builder's signed provenance cannot?
answer
- testimony versus a fact anyone can re-derive
- the builder is still one root of trust
- an attacker now needs all of them
- detective, public, no privileged access
- identical inputs, so a backdoor reproduces too
basics
~10 sIt turns testimony into a fact anyone can re-derive. Signed provenance is one builder's claim; independent agreement shows unrelated parties derived the same bytes, so subverting a single build platform no longer goes unchallenged.
solid answer
~50 sA signed provenance statement is testimony: a hardened builder asserts that this digest came from that source revision with those inputs, and a verifier accepts it because it trusts that builder's identity and hardening. Even at the top of the build track the builder is the root of trust, so a subverted build platform emits a perfectly valid statement over bytes that were never derived from the stated source. Two independent rebuilders agreeing on the digest is a different kind of evidence: it shows the bytes are derivable from the declared source and inputs by parties with no shared infrastructure or keys. An attacker now has to compromise every rebuilder, or the source itself, rather than one platform. It is also detective and public — anyone can rebuild and raise a mismatch without privileged access. What it does not show is that the source is benign or the pinned dependencies are safe; a backdoor in the reviewed source reproduces perfectly.
go deeper
Recall the core contrast: signed provenance is one builder's claim you have to trust, while matching independent rebuilds are something anyone can check for themselves.
Explain the mechanics of the shift — the builder stops being a single root of trust, and an attacker must subvert every rebuilder or the source instead of one platform.
Demonstrate the limits under pressure: shared poisoned inputs, fake independence, and a non-deterministic build that turns every comparison into noise and quietly removes the control.
Own the scope decision. Independent rebuild capability costs real engineering and coordination, so argue which artifacts — a fleet's base platform, a widely redistributed release — earn it and which do not.
## Two kinds of evidence The distinction underneath this question is between **attested** and **derivable** facts. Signed provenance is attested. A build platform states: this artifact, identified by digest, was produced from this source revision, by this build definition, with these inputs. The statement is signed under an identity, and a verifier accepts it because of what it believes about that identity — that the platform is hosted rather than run by the tenant, that its signing material is isolated from build workloads, that a build cannot forge or edit the statement about itself. Everything in that chain is a reason to **trust the issuer**. An independent rebuild is derivable. Someone takes the stated source revision and the stated inputs, runs the build in their own environment, and gets the same digest. Nobody has to be believed. The claim has been re-derived from scratch by a party with no relationship to the original builder. ## The residual risk that agreement closes Even a maximally hardened build platform is a **single root of trust**. If it is subverted — a compromised build image, a poisoned toolchain on the builder, an operator with legitimate access to the release path — it will emit provenance that verifies flawlessly and describes bytes that were never derived from the stated source. Every consumer policy downstream passes. That is precisely the shape of an attack on a widely distributed platform artifact: the compromise sits in the build, not in the source that everyone reviews, so source review sees nothing and signature verification sees nothing wrong. When two organisations in different jurisdictions, with different infrastructure, different toolchain provisioning and different operators, rebuild an OS distribution package and land on the same digest, that attack no longer works quietly. To keep the substituted bytes accepted, the attacker must compromise **every** rebuilder in the same way at the same time, or move the attack upstream into the source itself where review has a chance at it. The security model changes from "one platform must be clean" to "an N-way conspiracy must hold," and the check is **detective and public**: any third party with the source can perform it and shout, without access to the producer's systems. For a fleet's base platform — the packages every machine in an estate installs — that difference is the whole argument for reproducibility. The blast radius of one compromised builder is the entire fleet, and no amount of hardening on that builder is independently checkable from outside. ## What agreement does not prove This is where candidates overreach, and interviewers are listening for the limits. - **It says nothing about the source being benign.** A backdoor committed into the reviewed source reproduces perfectly, in every rebuilder, forever. Reproducibility binds bytes to inputs; it makes no claim about the goodness of those inputs. - **It says nothing about vulnerable dependencies.** A pinned dependency with a known flaw is faithfully baked into every matching rebuild. - **Shared bad inputs give shared bad output.** If all rebuilders consume the same poisoned pinned dependency or the same subverted compiler binary, they will agree — on the wrong artifact. Agreement proves consistency with the declared inputs, not that the inputs deserved trust. This is why toolchain provenance and rebuilder diversity in *how the toolchain itself is obtained* matter. - **Independence has to be real.** Two rebuilders in the same organisation, on the same image, with the same operators, produce correlated results. The evidence is only as strong as the diversity behind it. - **It does not identify the source revision for you.** You still need to know that the revision being rebuilt is the one you think it is, and that is what provenance and signing give you. Reproducibility is a check on the claim, not a replacement for it. ## Where it breaks in practice The control has one brittle dependency: the build must actually be deterministic. Take a service binary that embeds its build timestamp and the absolute path of the source tree on the build machine. Every honest rebuild differs byte-for-byte from the published artifact, so the comparison produces a mismatch every time and carries no signal at all — you cannot tell tampering from ordinary non-determinism. In effect the organisation has silently lost its only cross-check on a single trusted builder and is back to taking the platform's word, with the added cost of running rebuilds that always disagree. That is the strategic point about non-determinism on this leaf: it is not a cosmetic build-hygiene issue, it is the difference between having independent evidence and having none. Which artifacts you make deterministic is a decision about which artifacts you want anyone other than yourself to be able to verify.
- Your rebuild of a service binary yields a different digest from the published one. What have you learned?On its own, nothing conclusive. Binaries commonly embed build timestamps, hostnames or absolute source paths, so honest rebuilds differ. Until determinism is established you cannot distinguish tampering from ordinary non-determinism, and the comparison has no signal. The first job is to identify and remove the varying fields; only then does a mismatch mean anything.
- If releases are independently reproducible, can you stop generating provenance and signing?No. Reproducibility checks whether bytes follow from a claimed source and input set, but something has to make that claim in the first place and tie it to an accountable identity. Provenance names the source revision, builder and inputs; the signature says who vouches. Reproducibility is a check on that claim, not a substitute for it.
- What makes two rebuilders genuinely independent?Different organisations and operators, separate infrastructure, and independently obtained toolchains rather than the same prebuilt image. If both pull the identical compiler binary from the same host, a subverted toolchain compromises both and they will agree on the wrong output. Diversity in how the build environment itself is acquired is the part people skip.
Signed provenance is a notarised statement from one witness. Independent rebuilds are two strangers separately working the sum and getting the same total. You can doubt a witness; it is much harder to doubt the arithmetic.
saying these in an interview costs you the question
- Says a reproducible build proves the source has no backdoor
- Treats reproducibility as a replacement for provenance and signing
- Ignores that shared poisoned inputs make rebuilders agree
- Calls two rebuilders on the same image independent
- Reads a digest mismatch as proof of tampering