The Reproducible Build Becomes the Decay Test
A reproducible release proves something important at one moment. It does not prove that the same artifact can still be rebuilt after the ecosystem moves on.
The Paper
The paper is Understanding Build Reproducibility in the F-Droid Ecosystem, arXiv:2607.01890 [cs.SE]. The arXiv record lists Denise Nanni, Julien Malka, Stefano Zacchiroli, Théo Zimmermann, and Gabriele d'Angelo as authors, version 1 as submitted on July 2, 2026, and the comment as "2026 ACM Conference on Reproducibility and Replicability, Jul 2026, Delft, Netherlands." The PDF proceedings text identifies ACM REP '26 as running July 20-22, 2026 in Delft and describes the paper as 12 pages.
This is not an AI paper in the narrow model sense. It belongs here because it studies a cybercultural control that AI systems also depend on: the ability to prove that a distributed artifact came from inspectable source code, and to keep that proof meaningful after time, toolchains, repositories, and dependencies change.
Release-Time Trust Is Not Enough
F-Droid is a free and open source software distribution for Android. The paper says the project was founded in 2010, builds applications directly from source, and uses reproducibility checks to compare source-built outputs with the binaries distributed through its repository. In security language, that matters because users and auditors do not have to take a distributor's binary on faith if independent rebuilds can reach the same bytes.
The catch is time. A build that was reproducible when published may later become unrebuildable. Source code can disappear. Dependency repositories can remove artifacts. Build tools can change. Debian releases and Java versions can move. Metadata formats and scanning policies can evolve. The binary may still sit in an archive, but the path back from source to binary can become broken.
The paper distinguishes reproducibility over time from reproducibility in time. The first asks whether newer app versions are increasingly reproducible when published. The second asks whether an app version that was reproducible in the past can still be rebuilt and verified later. That distinction is the whole lesson: a release-time certificate and a long-term audit trail are different artifacts.
What Decayed
The authors built their dataset from F-Droid catalog data and reproducibility logs downloaded on February 17, 2026. After removing duplicates and filtering missing or non-reproducible records, disabled packages, and records without required repository metadata, the rebuild experiment contained 18,904 package versions that had previously been confirmed bitwise reproducible between September 2018 and February 2026.
They successfully rebuilt 15,831 of those 18,904 package versions, an 83.7 percent rebuild success rate. That is a strong result, but it also means that past reproducibility did not guarantee present rebuildability. The main failure mode was not mysterious nondeterminism. Missing dependencies accounted for about 76 percent of failed packages. The second largest category was source code that could no longer be retrieved, accounting for about 10 percent of failures.
Among package versions that did rebuild, the result was much better: 94 percent were still bitwise reproducible. The paper's conclusion is therefore precise. F-Droid's reproducible-build practice appears to hold up well when the original build can still be reconstructed. The bottleneck is the environment: external registries, source availability, dependency pinning, and historical build conditions.
The Time Capsule Standard
The practical standard is stricter than "publish the source." A distribution that wants durable verification needs source code, every external dependency, the build recipe, exact versions, toolchain details, base operating-system image, policy settings, and enough metadata to rerun the old build without guessing which ecosystem state once existed.
The paper recommends archiving external dependencies alongside source code and enforcing rigorous pinning of historical build environments. That sounds like infrastructure bookkeeping, but it is closer to institutional memory. If the dependency vanishes, the proof vanishes with it. If the build environment is underspecified, future auditors inherit a puzzle rather than a receipt.
The Spiralist Reading
Spiralism usually studies AI systems, agents, platforms, and belief machinery. Reproducible builds sit underneath all of them. An agent package, model-serving stack, mobile app, browser extension, data pipeline, audit tool, or safety harness can only be inspected later if its software ancestry remains rebuildable.
This is the same pattern as stale model memory, benchmark rot, and supply-chain prompts: a system produces a convincing state, then later loses the conditions that made that state checkable. The archive keeps the noun but loses the verb. It still has "source," "binary," "version," or "model," but no longer has the executable path that connects them.
A serious software supply-chain receipt should therefore include a rebuildability horizon. How long is the institution promising that the artifact can be rebuilt? Which dependencies are mirrored? Which source repositories are archived? Which base images are preserved? Which build logs are retained? Which person or organization is responsible when the old path breaks?
Limits
The study is specific to F-Droid and to package versions that were historically reproducible. It does not prove that every Android app, language ecosystem, Linux distribution, or AI package has the same failure rates. The authors also used legacy-aware build reconstruction and manual edge-case fixes that go beyond what ordinary users would do.
Those limits make the result more useful. The paper is not saying reproducible builds fail. It is saying that reproducibility is a living property of an ecosystem. If a public institution, safety lab, open-source project, or AI vendor wants users to trust an artifact years later, release-time reproducibility has to become preservation practice.
Sources
- Denise Nanni, Julien Malka, Stefano Zacchiroli, Théo Zimmermann, and Gabriele d'Angelo, Understanding Build Reproducibility in the F-Droid Ecosystem, arXiv:2607.01890 [cs.SE].
- arXiv PDF for Understanding Build Reproducibility in the F-Droid Ecosystem, checked for authors, venue metadata, F-Droid background, dataset construction, rebuild counts, failure causes, reproducibility results, recommendations, and limitations.
- arXiv listing page for Software Engineering, checked for current subject listing and comment metadata.