Field Notes

concept

Rebuildability

StatusStableUpdatedStands on1 sourceSupportsnotes

Rebuildability is the property that a software build can still be executed to completion today from the inputs recorded for it. It is logically prior to reproducibility: determinism is a claim about whether two builds agree, and there is nothing to compare until the build can be run a second time at all.

The two properties fail for unrelated reasons. A build is non-deterministic because of something inside it — an embedded timestamp, a filesystem ordering, a parallelism-dependent optimizer. A build stops being rebuildable because of something outside it: a dependency delisted from its registry, a source repository deleted, a compiler version no longer packaged, a base image whose distribution reached end of life. Fixing the first is an engineering task within the project. Fixing the second requires archives the project usually does not control.

Why the distinction has practical weight

Reproducibility is normally verified once, when an artifact is published, and the guarantee is then treated as a durable property of that artifact. Rebuildability decides whether the guarantee can ever be rechecked. An artifact that was verified in 2019 and cannot be rebuilt in 2026 carries a claim nobody can now audit, which is a weaker position than the original verification suggests.

This matters most for the uses that motivate reproducible builds in the first place. Retrospective auditing after a suspected compromise, long-term software preservation, and independent verification by a party other than the publisher all require running the build later than the publisher did, often much later.

Measured decay

The first study to measure this across a distribution’s history rebuilt 18,904 F-Droid app versions that had passed a reproducibility check at publication, covering September 2018 to February 2026. It completed 83.7% of them, with missing dependencies causing about 76% of the failures and unretrievable source code about 10%. Of the builds that did complete, 94% were still bitwise identical.1

The gap between those figures is the finding: determinism held up, and the capacity to test it did not. The same study reports that among apps once marked reproducible, the number still testable after five years had roughly halved.

Ecosystems differ sharply here, and the difference is architectural rather than cultural. Functional package managers that pin the complete dependency closure, such as Nix, retain rebuildability above 99% for packages several years old, while ecosystems that resolve dependencies against mutable external registries at build time inherit those registries’ availability.1 Android’s build model sits in the second group, which is why F-Droid’s decay is not evidence of neglect by that project specifically.

Preserving it

The mitigations follow from the failure causes rather than from cryptography:

  • Archive source code together with its transitive dependencies in a durable repository, and retrieve from that archive when an upstream host stops serving the original.
  • Record the build environment explicitly — toolchain versions, base image, and resolved dependency versions — rather than leaving it to be inferred from a publication date.
  • Retain or reproducibly regenerate build images, so a legacy build can be run in the environment it was made for.

  1. Understanding Build Reproducibility in the F-Droid Ecosystem, ACM REP ‘26. ↩↩

Built on 1 source (1 external).

Working out connections…