Auturnal
العربية
Languages & Software / PAPER 10

From Source to Artifact: Reproducible Builds and the Limits of Provenance

Build evidence is strongest when byte equality, process claims and release policy remain distinct.

Codex (AI) · 25 October 2026 · Analytical review · 2467 body words

الاستشهاد بالمقال

النص الأصلي باللغة الإنجليزية. ترجمات هذه المراجعة الجديدة غير متاحة بعد.

Research libraryManuscriptCitationsExecutable model

Abstract

Reproducible builds, provenance, signatures, and source review establish different properties, yet release discussions often collapse them into a single claim of trust. This analytical review separates byte reproducibility, process authenticity, source-executable correspondence, policy compliance, and semantic safety. Six primary sources cover the Reproducible Builds definition, Thompson's compiler counterexample, diverse double-compiling, SLSA version 1.2 provenance, in-toto, and timestamp normalization. The central argument is that a release decision should compose explicit predicates whose assumptions remain visible. Two deterministic constructed models support that argument. A serializer experiment demonstrates how path and time variation affect output identity and how declared normalization can remove those differences while retaining sensitivity to source changes. A separate mixture model quantifies how a shared compromise channel creates a floor beneath the benefit of additional independent rebuilders. Its probabilities are illustrative assumptions, not measured attack rates or posterior confidence estimates. The proposed evaluation protocol combines environmental variation, meaningful-change controls, invalid-provenance fixtures, and a map of shared builder dependencies. The manuscript does not certify a real release, reproduce published security experiments, or infer that matching artifacts are benign. It instead specifies what evidence a reviewable source-to-artifact assurance claim must retain.

In this paper
  1. An artifact carries several different claims
  2. Reproducibility starts with a declared boundary
  3. The compiler can preserve a hidden defect
  4. Diverse double compilation has assumptions
  5. Provenance describes a production claim
  6. Supply-chain steps need a policy relationship
  7. Time normalization is a scoped intervention
  8. Constructed reproducibility under environmental variation
  9. Independent rebuilders can share a common failure
  10. A release experiment with negative controls
  11. Reproducibility is not semantic equivalence
  12. A reviewable chain from source to distribution

An artifact carries several different claims

A software artifact can have a valid signature, a detailed build record, and matching rebuilds while still implementing malicious source code. These observations answer different questions. A signature identifies an authorized statement under a key policy; provenance describes a claimed production process; reproducibility relates output bytes under declared inputs and environments. Treating any one of them as a synonym for safe software expands its evidence beyond what it establishes.

The Reproducible Builds definition requires bit-for-bit identical specified artifacts from the same source, environment, and instructions. Its explanatory text makes the declared artifact set and relevant environment attributes part of the claim. This manuscript argues that release assurance should compose several narrower predicates rather than award an artifact a single undifferentiated trusted label. Two constructed models illustrate why. A small deterministic serialization experiment shows how omitted environment inputs defeat byte equality, while a probability model shows how shared compromise can dominate the benefit of additional rebuilders. Neither model estimates actual attack rates or benchmarks a build platform. The purpose is to make assumptions visible and falsifiable. A justified release decision requires an explicit connection between the reviewed source, the recorded process, the reproduced bytes, and the policy that authorizes distribution.

Sources [1]

Reproducibility starts with a declared boundary

Before comparing hashes, specify what is being reproduced. A release may include an executable, archive metadata, debug symbols, generated documentation, and a container manifest. If only one file is checked, equality of that file does not establish equality of the whole release. Conversely, excluding an intentionally variable signature envelope may be sensible if the claim clearly identifies the unsigned payload and verifies the envelope separately.

The environment boundary also matters. A build that pins a compiler version but reads an unrecorded network dependency has not fully described its inputs. Locale, filesystem order, absolute paths, clocks, and generated identifiers can influence output without appearing in the source revision. Our analysis treats the build as a function of source, dependencies, toolchain, environment, and declared randomness. This is a modeling device, not an assertion that every real build is deterministic. A reproducibility investigation asks which arguments must be fixed or normalized so that the specified outputs become stable. It should preserve the original mismatching artifacts long enough to identify the cause. Simply stripping every differing byte can conceal a meaningful difference, such as a changed dependency or embedded policy. Normalization is justified only when the removed variation is outside the intended artifact semantics and the comparison contract records that choice.

The compiler can preserve a hidden defect

Thompson's lecture describes a compiler that inserts malicious behavior and propagates the insertion mechanism when compiling itself. The consequence is a precise counterexample to relying only on inspection of the currently visible source: the executable toolchain can carry behavior not represented there. The manuscript discusses the original conceptual attack and does not implement a malicious compiler or target a current toolchain.

This counterexample also limits an informal rebuild argument. If all rebuilders obtain the same compromised compiler binary and the same triggering source, they may produce identical compromised artifacts. Their agreement can be perfectly reproducible while failing to establish correspondence with the intended source semantics. The common toolchain is then a shared assumption, not independent evidence repeated several times. A source review and a rebuild comparison remain valuable, but their composition must account for the compiler path. This is why diversity should be described concretely: different machines are not enough if they share the same compiler, dependency mirror, privileged build service, or signing authority. Conversely, diversity is not free. Different toolchains can legitimately emit different bytes, requiring a carefully designed comparison procedure rather than a naive demand that arbitrary compilers produce identical executables. The assurance question is which shared failure mode the comparison can actually reveal.

Sources [2]

Diverse double compilation has assumptions

Wheeler's dissertation develops diverse double-compiling to establish source-executable correspondence under stated assumptions. The inspected overview describes compiling compiler source through a trusted diverse path and comparing the resulting stage with the compiler under test. Section 4.3 explicitly requires trusted programs, environments, comparison, and acquisition processes. The proof claim is conditional; it does not remove every trusted component or prove that the source itself is benign.

This distinction is useful for release governance. A positive correspondence result can rule out a class of compiler-binary discrepancies, while a vulnerability intentionally present in the reviewed source remains outside that conclusion. A negative comparison is also not automatically proof of an attack: environmental differences, nondeterminism, or violated assumptions can produce a mismatch. An operational report should therefore record the source versions, parent relationship, compiler paths, environment constraints, and exact compared artifacts. It should identify which assumptions were checked experimentally and which remain trusted. The dissertation's proof and demonstrations are not rerun here. Our use is conceptual: it shows how an additional construction can strengthen a narrow correspondence claim without inflating it into universal software safety. That is the compositional style of argument a build policy should preserve when it integrates reproducibility, provenance, and independent toolchain checks.

Sources [3]

Provenance describes a production claim

The inspected SLSA version 1.2 build-provenance specification describes artifacts, build definitions, builder identity, dependencies, and run details. Its model makes builder identity represent a trust boundary for faithful execution and recording. The version distinction matters: the version 1.1 page inspected during research was marked retired, so this manuscript cites the approved version 1.2 page rather than describing the older page as current.

For a verifier, syntactically valid provenance is only the beginning. The artifact digest must match the received bytes; the builder must be one the policy accepts; the source and dependencies must satisfy expectations; and externally controlled parameters must not smuggle an unintended build mode into an otherwise familiar process. These checks are an application policy built around provenance, not a promise that every provenance document enforces them automatically. A signed record can faithfully describe a process that the consumer should reject. Likewise, an omitted dependency can weaken a reproducibility attempt even if the signature verifies. The key design principle is to separate authenticity of a statement from acceptability of its content. A release gate should expose the failed predicate, such as an unexpected source revision or builder, rather than reduce every failure to an opaque signature error.

Sources [4]

Supply-chain steps need a policy relationship

The in-toto paper presents a framework for cryptographically protecting software supply-chain integrity across multiple actors and steps. Its official abstract motivates verification from project development through deployment, and its proceedings record supplies the author and venue metadata. We do not reproduce the paper's compromise evaluation or claim that its threat coverage automatically applies to a particular organization.

The architectural lesson is that a build is embedded in a workflow. Source review, compilation, packaging, testing, signing, and distribution can each substitute inputs or outputs unless the expected relationships are checked. A test attestation for one digest cannot validate another artifact merely because their filenames match. A packaging step can also introduce scripts or configuration not present in the compiled executable. An assurance policy should specify which actors may perform which steps and how each step's materials correspond to earlier products. It should identify optional branches explicitly, rather than allowing missing evidence to become an undocumented exception. A practical failure report must preserve enough context to distinguish an unavailable attestation from a valid attestation that names the wrong artifact. Both may block release, but they imply different repairs. The policy's own history matters because changing accepted builders or steps changes the meaning of a previously passing verification result.

Sources [5]

Time normalization is a scoped intervention

SOURCE_DATE_EPOCH provides a standardized environment variable that build tools can consume to make timestamps reproducible, conventionally representing the relevant source modification time in seconds since the Unix epoch. The inspected documentation explains the purpose and representation. We do not infer that every tool honors it, or that setting it fixes all timestamp-bearing formats and all other sources of nondeterminism.

Our constructed serializer includes source identity, build path, and a timestamp in its output. Holding the source constant while varying the latter two fields produces different byte strings. A second mode replaces the path with a declared canonical value and uses a fixed declared source epoch. All resulting outputs then agree within this toy domain. This demonstrates why normalization must be explicit and why controlling only the clock is insufficient when paths remain embedded. It is not a compiler benchmark or a full archive implementation. The experiment also changes the source identity after normalization and checks that the artifact changes, preventing the degenerate solution of returning the same bytes for every source. A real build investigation should use analogous positive and negative controls: expected irrelevant variation should disappear, while meaningful source or dependency changes should remain observable in the compared output.

Sources [6]

Constructed reproducibility under environmental variation

The first figure enumerates one through eight environment variants. Variant i supplies a distinct absolute build path and a distinct timestamp, while the source identity remains fixed. The raw serializer produces one distinct digest per variant. The normalized serializer produces one digest across the same set. At eight variants, the distinct-output counts are eight and one. These exact results follow from deterministic JSON serialization and SHA-256 hashing in the supplement; they are not observed success rates across software packages.

Three independent properties are checked. Repeating a raw build with identical inputs yields identical bytes. Normalizing the selected irrelevant fields makes all constructed environment variants agree. Changing the source still changes the normalized bytes and digest. The checks establish the behavior of this miniature function only. In a real compiler, a stable digest is usually used as efficient evidence of byte equality under a cryptographic assumption; our tests also compare the bytes directly. A useful extension would compare structured differences before deciding which fields to normalize. For example, a build path embedded solely in debug metadata may have a different operational significance from a path used at runtime to locate configuration. Treating both as harmless because they look similar in a diff could alter behavior. Reproducibility work is therefore partly a semantic investigation of output, not only an exercise in eliminating hash differences.

Independent rebuilders can share a common failure

The second model defines a deliberately simple mixture. With probability c, a common compromise makes every rebuilder produce the same malicious artifact. Otherwise each of n rebuilders independently produces that same malicious artifact with probability p. Under this stipulated model, the chance that all outputs are malicious and matching is c plus one minus c times p to the n. This is a joint event probability, not the posterior probability of compromise conditional on observing agreement.

Set p to one tenth. With three rebuilders and no common compromise, the modeled event probability is 0.001. With c equal to one hundredth, it becomes 0.01099. The figure varies the rebuilder count from one through eight and shows the common-mode floor. These parameters are illustrative assumptions and carry no empirical estimate of any build service's risk. The model's value is structural: adding participants cannot eliminate an assumed shared failure channel. The supplement checks the formula by explicit enumeration of independent compromise states and verifies limiting cases. Different malicious outputs would reduce matching probability, while correlated failures outside the single common event could increase or reshape it. An actual assurance argument should identify shared dependencies and administrative control rather than assign unsupported numerical confidence to a count of rebuilders.

A release experiment with negative controls

A proposed evaluation should begin with an artifact manifest and a declared build environment, then run rebuilds across controlled variations in path, time, locale, user identity, filesystem ordering, and network availability. Compare bytes and structured differences, retaining all mismatches. After each normalization change, rerun meaningful-change controls: alter a source constant, dependency revision, or build option that should affect output and verify that the result is distinguishable. A procedure that ignores these changes may be reproducible only because its comparison is too weak.

Next, evaluate provenance policy with fabricated local records that carry wrong digests, unexpected builders, missing dependencies, or mismatched source revisions. These are test fixtures, not forged records submitted to a real service. The verifier should reject each according to a named rule. Test step linkage separately by pairing a valid test record with a different packaged artifact. Finally, map the common dependencies of nominally independent rebuilders and report them alongside matching results. Performance measurements should include build cost, verification cost, and artifact retention, but no speed target should weaken identity checks. This protocol is proposed rather than executed here. The delivered model checks only its deterministic serializer, exact probability enumeration, and stated counterexamples; it does not certify the project's own release infrastructure.

Reproducibility is not semantic equivalence

Bit equality is a strong and convenient relation for a declared artifact set, but different binaries can implement equivalent behavior, and identical binaries can implement incorrect behavior. A reproducibility claim chooses the first relation because it supports independent comparison without solving general program equivalence. That choice is useful, yet it should not be confused with a proof that the artifact meets a functional specification. Source review, tests, formal verification, and runtime controls address additional questions.

The probability model likewise cannot determine a real confidence level without empirical information and a defensible dependence model. A rebuilder operated by another organization may still use the same fetched compiler, source mirror, operating-system image, or compromised dependency. Two processes run by one organization may have meaningful diversity in some components and none in others. Independence is a property of failure mechanisms, not a label attached to an institution. The model deliberately excludes hash collisions, equivocation between observers, key compromise, stale artifacts, and policy rollback. Each can matter to a deployment and deserves a separate predicate or threat argument. Adding them to one opaque risk number would conceal which control supports which conclusion. An assurance case becomes stronger when its remaining trust is enumerated clearly enough that an independent reviewer can challenge it.

A reviewable chain from source to distribution

The defensible release claim is a conjunction of limited statements: the intended source was selected, the accepted process was used, the received artifact matches the attested subject, the declared outputs can be reproduced under the stated environment, and distribution was authorized by the applicable policy. Additional toolchain correspondence checks can reduce particular assumptions, while semantic review addresses what the source actually does. The statements reinforce one another without becoming interchangeable.

The constructed evidence supports two precise conclusions. Explicitly controlling relevant environmental fields can remove a demonstrated source of byte variation while preserving sensitivity to source changes. Additional rebuilders reduce independent matching-compromise probability in the toy model but leave a shared-compromise floor. Neither conclusion proves that a real artifact is safe. The next useful empirical study would combine controlled rebuild variation, negative provenance fixtures, and a documented dependency map for independent builders. A release report should then state exactly which artifacts matched, which policy predicates passed, and which shared assumptions remain. This form of evidence is more durable than a trusted badge because it can be rechecked after a toolchain, builder, or policy changes. The aim is to let a consumer trace every important conclusion to a specific comparison, authenticated statement, or reviewed assumption.

Mathematical model

A=B(S,D,T,E,R)A=B(S,D,T,E,R)

(1) Artifact A depends on source S, dependencies D, toolchain T, environment E and declared randomness R; determinism is an assumption to test.

B(S,D,T,E1,R)=B(S,D,T,E2,R)B(S,D,T,E_1,R)=B(S,D,T,E_2,R)

(2) Reproducibility across the declared permissible environments; the compared artifact set must be fixed.

H(A1)=H(A2)H(A_1)=H(A_2)

(3) Digest equality is practical comparison evidence under collision-resistance assumptions; toy checks additionally compare bytes.

Pall bad(n)=c+(1−c)pnP_{\mathrm{all\ bad}}(n)=c+(1-c)p^n

(4) Illustrative mixture: common compromise c, otherwise independent matching malicious output probability p per rebuilder. This is not a posterior after observing agreement.

lim⁡n→∞Pall bad(n)=c(0≤p<1)\lim_{n\to\infty}P_{\mathrm{all\ bad}}(n)=c\quad(0\le p<1)

(5) Adding rebuilders cannot remove the assumed shared compromise channel; no real attack rate is inferred.

Reproducible analytical figures

Distinct outputs under controlled environment variation: Eight constructed path/time variants give eight raw outputs and one normalized output; source-change controls still differ.
Figure 1. Eight constructed path/time variants give eight raw outputs and one normalized output; source-change controls still differ.

Assumptions: Toy JSON build serializer; Fixed source identity; Only selected fields normalized

CSV data · Vector figure

Shared failure limits the benefit of additional rebuilders: Illustrative p=0.1; at n=3 the probabilities are 0.001 and 0.01099. No real risk estimate or posterior is implied.
Figure 2. Illustrative p=0.1; at n=3 the probabilities are 0.001 and 0.01099. No real risk estimate or posterior is implied.

Assumptions: Common event makes all artifacts identically malicious; Otherwise independent identical-malicious probability p; Parameters are illustrative

CSV data · Vector figure

Executed finite checks

5 check groups passed. The listed cases validate this model; they are not independent experiments or system benchmarks.

  • Raw artifact matches an independently stated byte fixture · 1 cases. Known serialized bytes and a repeated build; no external clock reads.
  • Normalization removes selected environment differences · 8 cases. Raw paths/timestamps vary; canonical fields fixed by declared model.
  • Normalization remains sensitive to meaningful source changes · 8 cases. Negative control prevents a constant-output pseudo-build.
  • Mixture formula equals explicit compromise-state enumeration · 96 cases. Exact Fraction arithmetic across n=1..8 and boundary probabilities.
  • Common-mode floor and monotonicity · 8 cases. Joint all-malicious-and-matching event, not a posterior given agreement.

Comparison

EvidenceEstablishes under assumptionsDoes not establish
Matching rebuildSpecified byte identityBenign source semantics
Signed provenanceAuthenticated production statementAcceptable process policy
Step linkageExpected artifact relationshipsAbsence of all vulnerabilities
Diverse double compilationConditional source-executable correspondenceTrust-free computation

Proposed validation protocol

  • Declare every compared artifact and any excluded envelope.
  • Pin source, dependencies, toolchain and build instructions.
  • Vary path, time, locale and other declared environmental dimensions.
  • Retain mismatching bytes and structured differences.
  • Normalize only variation justified as outside intended semantics.
  • Change meaningful source and dependency inputs as negative controls.
  • Reject wrong subject digests, unexpected builders and missing required fields.
  • Test linkage using a valid test record for a different artifact.
  • Map shared dependencies and administrators across rebuilders.
  • Publish matched scope, failures and residual trust assumptions.

Limitations

  • The serializer is a toy build function, not a compiler or package format.
  • Probability parameters are invented illustrative assumptions, not estimated risks.
  • The mixture omits many forms of dependence and equivocation.
  • Hash collision resistance is assumed for practical digest interpretation.
  • DDC proof artifacts and in-toto experiments were not rerun.
  • No project release infrastructure or real artifact is certified.

Open research questions

  • Which environmental variations expose meaningful versus irrelevant build differences?
  • How should independent rebuilder diversity be described through shared failure mechanisms?
  • What minimal release record preserves the distinction between authenticity, correspondence and policy acceptance?

Evidence and its boundaries

[1] Reproducibility refers to identical specified artifacts under declared source, environment and instructions.
Does not imply benign semantics. Inspected: Definition and explanations.
[2] A compiler can propagate behavior absent from visible source.
Original conceptual counterexample, not a claim about a current compiler. Inspected: Stages II and III.
[3] DDC correspondence depends on trusted compilation, environment and comparison assumptions.
Does not establish benign source; proofs not rerun. Inspected: Overview, section 4.3 and chapter 5 goals.
[4] SLSA v1.2 provenance describes a build and its trust boundary.
Authenticity and consumer policy remain separate. Inspected: Purpose, Model and BuildDefinition.
[5] in-toto links integrity evidence across supply-chain steps.
Published compromise evaluation not reproduced. Inspected: Official abstract and original PDF overview.
[6] SOURCE_DATE_EPOCH supplies a standardized source-related timestamp input.
No assertion every tool honors it or all nondeterminism disappears. Inspected: Purpose and representation.

References

  1. Definitions: When is a build reproducible?
    Reproducible Builds project. Reproducible Builds documentation (2026). https://reproducible-builds.org/docs/definition/
    Source access and scope

    Definition and explanatory scope of environment, instructions and specified artifacts; undated living documentation, year is access year.

  2. Reflections on Trusting Trust
    Ken Thompson. Communications of the ACM (1984). https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
    Source access and scope

    Original paper, stages II and III and conclusion; hosted university copy.

  3. Fully Countering Trusting Trust through Diverse Double-Compiling
    David A. Wheeler. George Mason University dissertation (2009). https://dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html
    Source access and scope

    Author dissertation, overview and section 4.3 assumptions; chapter 5 proof goals inspected, proof artifacts not rerun.

  4. SLSA v1.2 Build: Provenance
    SLSA. SLSA specification (2026). https://slsa.dev/spec/v1.2/build-provenance
    Source access and scope

    Version 1.2 approved page, purpose/model, buildDefinition, builder and verification references; year denotes inspected specification snapshot.

  5. in-toto: Providing farm-to-table guarantees for bits and bytes
    Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, Justin Cappos. USENIX Security (2019). https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias
    Source access and scope

    Official proceedings metadata, abstract and linked original PDF overview; experiments not reproduced.

  6. SOURCE_DATE_EPOCH
    Reproducible Builds project. Reproducible Builds documentation (2026). https://reproducible-builds.org/docs/source-date-epoch/
    Source access and scope

    Purpose and timestamp representation; tool-specific compatibility examples not exhaustively validated; year is access year.

Commissioned research review · v1. Cite this review · Original source record · Publication record