skip to content

An auditor rebuilds a shipped ledger image from its source revision and gets a different digest — what does that prove?

level: seniorimportance: should knowfreq 42%

answer

  1. evidence needs a baseline first
  2. noise and tampering look alike
  3. build it twice before you accuse
  4. a match links artifact to source
  5. a match says nothing about quality

basics

~20 s

By itself, almost nothing. Unless that build was already known to produce the same bytes twice, a mismatch cannot separate tampering or an undeclared input from ordinary build non-determinism, so it only becomes evidence once reproducibility has been established first.

solid answer

~50 s

A rebuild comparison is only as informative as the build's determinism. If two honest runs of that build routinely differ — because of a stamped clock, file ordering or a base that re-resolved — a mismatch tells the auditor nothing about the shipped artifact, and worse, it makes a genuine substitution indistinguishable from noise. So the first job is to show the build is byte-reproducible: rebuild it twice yourself, from the same revision and the same pinned base, and get one digest. Only then is a mismatch against the release a real finding — those bytes were not produced by that source under that recipe, and you chase the first divergent layer. A *matching* digest is narrow evidence too: it links the artifact to the source and the recipe, and says nothing about whether that source was reviewed or what is inside it.

go deeper

for a junior

Know that comparing a rebuild's digest against the released one only works if that build produces the same bytes every time it runs.

for a middle

Explain why non-determinism destroys the comparison: a stamped clock or a re-resolved base produces the same mismatch that substituted code would.

for a senior

Demonstrate the order of work — prove determinism by rebuilding twice yourself, then treat a mismatch against the release as a real finding and chase the first divergent layer.

for a principal

Decide which releases are worth holding to a re-derivable standard, and be ready to say plainly what you can and cannot show an auditor about the rest.

## What the comparison actually tests Re-deriving a release means running the recorded build again, from the recorded source revision and the recorded base bytes, and comparing the digest you get with the digest that shipped. The comparison tests exactly one proposition: **these bytes follow from that source under that recipe**. It is a strong proposition when it holds, because a digest is derived from content — there is no way to make two different artifacts share one. But the test is a *difference* test, and a difference test needs a baseline. Without one, you cannot read the result. ## Why non-determinism destroys the evidence Suppose the build stamps the clock into a generated file, or assembles layers in filesystem order, or names its base by a movable reference. Then two honest runs already differ. Now a rebuild of last year's release differs too — and it would have differed whether or not anyone touched anything. | Baseline | A mismatch means | An auditor can conclude | |---|---|---| | Determinism never established | the bytes differ, cause unknown | nothing about the release | | Two honest runs already match | something real differs: source, an undeclared input, or the artifact | a finding worth investigating | That is the whole shape of the answer. The mismatch is not wrong; it is **uninformative**, and treating it as an accusation is as much a mistake as ignoring it. A team that reports "the release does not reproduce" without having ever built it twice has measured its own toolchain, not its release. ## Establishing the baseline before the audit 1. Rebuild the release's source revision **twice in a row**, with the base pinned by digest, and compare the two results to each other, not to the release. 2. If those differ, fix the non-determinism first — normalised file times and ordering, no wall clock in a layer, a fixed build path — and repeat until they agree. 3. Only now compare a fresh rebuild against the digest that shipped. 4. If that comparison fails, find the **first divergent layer** and map it back to a step, an input or a file that is not what the recorded recipe said it was. 5. Report what differs, not what you suspect: the finding is "these bytes did not come from this source under this recipe", and the cause is the next investigation. ## What a mismatch can legitimately mean Even with a solid baseline, a mismatch names a difference, not a villain. Ordinary causes include: - the recorded source revision is not quite what was built — a local change that never landed; - an input nobody declared: a file present on the original machine, a value read from the environment; - the base bytes recorded and the base bytes actually used are not the same; - a step that was itself changed since the release, so the *recipe* moved rather than the source; - and, genuinely, an artifact that was modified or replaced after it was built. All of those are worth knowing. None of them is established by the mismatch alone. ## What a match does and does not say A matching digest is a link, and only a link: - **It says**: the released bytes are what that source revision produces under that recipe, so anyone who reviews the source is reviewing the thing that shipped. - **It does not say**: the source was reviewed, the dependencies it pulled in are sound, the build steps were safe, or the artifact is free of known flaws. Those are different questions with different evidence. The practical value is that it collapses a long trust chain into something checkable. Without reproducibility, "this image came from that source" is an assertion somebody makes. With it, the assertion is a claim anyone with the source can test for themselves — which is why it is worth the effort on the releases an auditor will come back to, and why it is the specific property a re-derivation request is asking about. ## The order of work, stated plainly Determinism first, comparison second, attribution third. Skipping the first step is the common failure: it turns a genuine control into a source of false alarms, and after a few of those nobody rebuilds anything and the control is gone.

  • What must be true before a digest mismatch is evidence of anything?
    Two honest runs of that build, from the same source revision and the same digest-pinned base, must already produce one digest. Once that baseline holds, a third run that differs is pointing at something real: a different source than recorded, an input nobody declared, or bytes that did not come from this build at all.
  • Your rebuild matches the released digest — what does that still not tell you?
    It ties the bytes to that source revision and that recipe, and nothing more. It does not say the source was reviewed, that the components inside it are free of known flaws, or that the recipe itself was safe. Reproducibility answers "did this source make these bytes", never "are these bytes good".

A recipe that yields a visibly different cake every time cannot be used to show that nobody swapped an ingredient. Make the recipe repeatable first, and only then does a difference mean something.

saying these in an interview costs you the question

  • Treats any digest mismatch as proof the release was tampered with
  • Assumes a matching rebuild proves the shipped code is safe
  • Calls a release unreproducible without ever building it twice
  • Ignores that the rebuild must follow the recorded recipe
  • Believes a rebuild is only valid on the original build machine