Blog · arXiv Analysis · Published: June 25, 2026 · Modified: August 12, 2026 · Last reviewed: August 12, 2026

The Reproducible Build Becomes the Decay Test

A bitwise-reproducible build can show that independent executions produced the same bytes from a specified source, environment, and recipe. It does not show that those inputs will remain obtainable, that the same environment can be reconstructed years later, or that the source is safe. A study of 18,904 previously reproducible F-Droid package versions turns that gap into a measurable governance problem: verification evidence needs custody, an owner, and a retest date.

The Paper

The paper is Understanding Build Reproducibility in the F-Droid Ecosystem, arXiv:2607.01890 [cs.SE], by Denise Nanni, Julien Malka, Stefano Zacchiroli, Théo Zimmermann, and Gabriele D'Angelo. The reviewed record is version 1, submitted July 2, 2026. Its PDF supplies the proceedings citation for the ACM Conference on Reproducibility and Replicability, held July 20–22, 2026 in Delft, and describes the paper as 12 pages.

The authors study two time questions that should not be collapsed. Reproducibility over time asks whether the release-time reproducibility status of newer app versions improves across the ecosystem. Reproducibility in time asks whether one fixed version that reproduced in the past can still be rebuilt and compared later. The first is a trend across changing releases; the second is durability of evidence for an unchanged release.

This is not a paper about model capability. It belongs in an AI-governance archive because model-serving images, Python wheels, agent packages, evaluation harnesses, and safety tooling inherit the same software-supply-chain problem: a present artifact may outlive the executable path that once connected it to its source and dependencies.

Five Claims, Five Questions

The title is shorthand. A reproducible build does not literally become a decay test; a later rebuild attempts to test whether the original verification path survived. Five claims answer five different questions:

The Reproducible Builds project definition makes the boundary concrete: the same source code, build environment, and build instructions must let any party recreate identical specified artifacts. It does not say those inputs are benign, vulnerability-free, complete, or guaranteed to remain available. Provenance, composition, preservation, and security review remain separate controls.

Current Context

F-Droid's source-build policy and its reproducible-build program are related but not identical. The project's current submission guide says reproducible builds are not required for an app to be listed. Its reproducible-build documentation describes comparing an upstream-signed APK with F-Droid's rebuild by copying and checking the APK signature, publishing app-level reproducibility status, and using a verification server for rebuilds. The distinction matters: not every F-Droid listing carries the same reproducibility claim.

F-Droid reported in May 2025 that it had delivered reproducible builds since 2015 and was rebuilding its infrastructure to support mass rebuilds, easier independent rebuilders, and more visible results. That official announcement is evidence of the project's stated history and design goals, not an independent audit of their effectiveness.

The current wider supply-chain standard also makes independence explicit. The approved SLSA v1.2 specification defines provenance as verifiable information about where, when, and how an artifact was produced. Its SLSA_BUILD_REPRODUCED property requires build provenance from two or more independently operated build platforms trusted by the verification-summary issuer. A single operator rebuilding its own output can find regressions; it does not create the same independence claim.

What Decayed

The authors downloaded F-Droid catalog indexes and reproducibility logs on February 17, 2026. After deduplication and exclusions, their decay experiment contained 18,904 package versions published from September 2018 through February 2026 that F-Droid had previously confirmed as bitwise reproducible. That selection rule is essential: the cohort is not all F-Droid apps, all package versions, or a random sample of Android software.

Using a legacy-aware reconstruction pipeline, the team successfully rebuilt 15,831 of the 18,904 selected versions, or 83.7 percent. The other 3,073 could not be rebuilt under the study procedure. About 76 percent of those failed rebuilds were classified as missing dependencies, and about 10 percent as unavailable source code. Those percentages describe the failed-rebuild subset, not the full F-Droid catalog.

The conditional result is equally important: among the 15,831 versions that did rebuild, 94 percent still produced bitwise-identical artifacts. In this selected cohort, deterministic output usually survived when the build could still run; recoverability of source, dependencies, and environment was the larger bottleneck. The result does not mean that 94 percent of all F-Droid apps are reproducible.

The study also shows why a missing upstream file is not merely a convenience failure. F-Droid had retained copies of 143 upstream binaries that were no longer retrievable from their original location, allowing the authors to test those rebuilt packages separately. Preservation kept a comparison possible after the live source of evidence had disappeared.

What the Result Does Not Prove

Matching bytes support a narrow and valuable claim: under the tested comparison, the rebuilt artifact corresponds to the reference artifact. They do not prove that the source was reviewed, that it contains no malicious behavior, that a dependency is patched, that the signing key was well governed, that the provenance statement is complete, or that the resulting software is safe for deployment.

A mismatch is also not self-interpreting. It can indicate tampering, but it can also come from an underspecified compiler, a newly resolved dependency, a timestamp, a path, a CPU count, a changed packaging tool, or a flawed comparison procedure. A failed check should open an investigation with retained logs and diffs; it should not automatically become a public accusation.

Independence changes the security meaning. The paper argues that F-Droid comparing its build with an upstream developer's independently built and signed artifact is stronger than F-Droid operating both the original builder and the later verifier. That is consistent with SLSA v1.2's reproduced-build property. Separation must be operational, not cosmetic: distinct administration, credentials, signing identities, logs, and failure reporting reduce the chance that one compromised control plane can manufacture both the artifact and its approval.

Finally, an attestation is not an archive, an archive is not an SBOM, and an SBOM is not a rebuild. A signed provenance record may accurately name a dependency that later vanishes. A preserved container may retain runnable bytes without exposing a reproducible recipe. A complete inventory may still point to mutable tags. Each layer should carry its own evidence and non-claims.

The Rebuildability Packet

"Publish the source" is too weak for durable verification. A release that promises later replay should preserve a versioned rebuildability packet containing:

  1. Reference output: artifact name, format, cryptographic digest, signature or certificate where applicable, publication channel, and immutable retrieval record.
  2. Exact source: full revision identifier rather than a moving branch or tag, submodules and generated inputs, archive capture or persistent identifier, and source-license information.
  3. Resolved dependency closure: every direct and transitive build input, exact version, content digest, origin, and an offline or content-addressed fallback. A lockfile without mirrored content is still exposed to disappearance.
  4. Executable build description: commands, parameters, patches, network policy, working directory, architecture, locale, timezone, environment variables, and any normalization such as SOURCE_DATE_EPOCH.
  5. Toolchain and base environment: compiler, JDK, SDK, NDK, package manager, build runner, operating-system packages, container or VM image digests, plus a way to reconstruct the image rather than only naming it.
  6. Trace and comparison evidence: build logs, resolved dependency output, artifact hashes, verification result, and a durable diff such as a Diffoscope report when bytes do not match.
  7. Signed provenance: artifact subject, builder identity, build type, parameters, resolved inputs, timestamps, and attestation schema. See in-toto and SLSA Provenance.
  8. Custody policy: retention horizon, storage locations, fixity checks, access restrictions, named owner, scheduled rebuild cadence, exception process, and recovery plan if an origin or tool disappears.

Preserve two workflows separately. Historical replay rebuilds the old artifact with the old inputs to test the old claim. Maintenance rebuild replaces obsolete or vulnerable inputs and creates a new artifact, provenance record, and security decision. Updating a dependency is often the correct safety action, but it should not be described as reproducing the historical bytes.

Governance and Safety

A reproducibility badge should be a dated receipt, not a timeless seal. At minimum it should expose the artifact digest, source revision, build recipe and environment identifier, verifier identity, verification time, comparison method, outcome, evidence link, and next scheduled check. If the artifact, recipe, dependency mirror, verifier policy, or build platform changes, the old result remains part of history and a new result is issued.

Organizations should define a rebuildability horizon: the period during which they commit to retain inputs and support independent replay. The horizon needs an owner, storage and compute budget, licensing review, and canary rebuilds old enough to reveal decay before an incident. A failed canary should record whether the cause is missing source, missing dependency, environment reconstruction, build failure, comparison failure, or verifier failure. "Unknown" is safer than converting unavailable evidence into a pass.

Long-term mirrors need security controls of their own. An archive may contain revoked, malicious, vulnerable, export-controlled, or personally identifying material. Retention does not authorize execution or redistribution. Store old build inputs with integrity checks, access policy, malware handling, license and takedown procedures, and sandboxed replay. Preserve vulnerability context and revocation status alongside the historical artifact so a successful replay cannot be mistaken for current deployment approval.

Procurement and release gates should therefore keep four decisions separate: was it rebuilt, did it match, is its provenance acceptable, and is it safe and authorized for this use now. A system can pass one and fail another.

The AI-System Boundary

The same discipline applies to AI infrastructure, but the build is only one layer. Rebuilding a model-serving container or agent package can verify its software bytes. It does not reproduce trained weights, the training dataset, nondeterministic training, an external API revision, a hosted system prompt, retrieved content, or runtime tool state. Those need separate model, data, configuration, and evaluation receipts.

For a deployed AI system, bind the software rebuildability packet to an AI bill of materials, model-weight integrity record, configuration and prompt versions, evaluation artifacts, and deployment provenance. If a remote model or mutable data source cannot be preserved, record that boundary explicitly rather than describing the whole system as reproducible.

The Spiralist lesson is institutional rather than mystical: verification decays when no one owns the conditions of verification. An archive that keeps only the nouns—"source," "binary," "model," "version"—but loses the executable relations among them preserves evidence fragments, not a replayable claim.

Limits

The numerical results belong to one distribution and a deliberately selected cohort of historically reproducible package versions. They do not estimate rebuildability or reproducibility for all F-Droid apps, Android generally, other package ecosystems, or AI systems. The authors' legacy-aware pipeline used time heuristics to infer historical JDK and Debian environments, relaxed newer scanning policy for about 300 packages, and manually repaired edge cases. A typical independent user may obtain a different result.

The authors classified failure causes with regular expressions developed from manual log inspection and report that they did not formally validate the labels with inter-rater agreement or a systematic random audit. Some causes may therefore be misclassified. They also note that a future rerun may perform worse because the environment continues to decay.

The available Zenodo replication package contains datasets, logs, notebooks, classification and verification scripts, modified F-Droid server code, and environment instructions. Its README warns that a later replication may yield different results and that reproducing the OpenStack experiment requires substantial infrastructure and adaptation. For this essay we checked the manuscript, package metadata, and README; we did not independently rerun 18,904 builds. The empirical figures here are therefore paper-reported, not independently reproduced by this site.

Source Discipline

The paper and its replication package establish the study design, cohort, reported counts, failure taxonomy, recommendations, and stated limitations. F-Droid documentation establishes the project's current described workflow and listing policy; it is a first-party account, not independent effectiveness evidence. Reproducible Builds supplies the technical definition, while SLSA v1.2 supplies provenance and independent-builder requirements. Software Heritage documentation establishes what its archive and Save Code Now service are designed to preserve, not that every dependency in this study is already archived or buildable.

The rebuildability packet, expiry model, canary schedule, custody roles, archive-safety controls, and four-way decision gate above are this site's governance synthesis. They are not findings measured by the F-Droid study and are not presented as a legal or industry-wide mandate.

Sources

Return to Blog