NixOS reproduces a complete minimal installation ISO independently

Rebuilding every package individually does not establish that an installation image can be reproduced. The image assembly can introduce its own differences, and a public cache can contain artifacts whose history does not match the comparison being attempted. An end-to-end result needs the final image as well as the packages inside it to agree.

The October 29 NixOS report announces an independent rebuild matching a Hydra-published minimal installation ISO byte for byte. The report includes the packages inside the image and the assembly of the ISO itself. It also says the rebuild compiled the dependencies needed to produce the image instead of fetching them from the binary cache.

I value Nix's declared-input model, but I regard an independent byte comparison as a separate kind of evidence. A build description states what should happen. Repeating the computation on another installation and obtaining the same artifact tests whether the process actually produces that result.

The claim covers a particular artifact

The report identifies an x86_64-linux minimal ISO and links its Hydra build. It provides the Nixpkgs revision 63678e9f3d3afecfeafa0acead6239cdb447574c, along with revision-count metadata used for the rebuild. Those identifiers make the result more specific than a statement that NixOS generally supports reproducibility.

The release jobset at that revision defines the combined NixOS and Nixpkgs release jobs. Its release-critical aggregate includes minimal ISO jobs alongside other installation images and system tests. The reported target is one identified output of that broader release machinery.

This scope matters because agreement on one artifact does not establish agreement on every image the jobset can produce. The announcement lists other installation media, including the GNOME ISO, as possible next milestones. It does not claim that all of those artifacts have already passed the same independent comparison.

The byte-identical ISO result is nevertheless stronger than evidence about a collection of package outputs alone. It includes how the chosen image combines its contents. The final artifact is what a user downloads and boots, so verifying its assembly closes a gap that package-level checks leave open.

An earlier milestone stopped short of the final image

The report explains why this is different from the project's earlier reproducibility announcement. In 2021, the packages needed for the minimal ISO had been tested individually for reproducibility. Rebuilding the complete ISO still introduced differences.

According to the October account, remaining problems in the Hydra cache and image creation prevented that earlier package-level result from becoming a complete ISO match. Subsequent regressions also interrupted progress, including a problem attributed to upstream Python 3.10. The new report says the contributors could finally validate the complete chain for this image.

This history clarifies what a reproducibility percentage means. A count of individually agreeing package builds measures a property of those packages under their tests. It does not automatically describe the determinism of the operation that assembles them into a filesystem image and bootable ISO.

An image can include generated metadata or filesystem structures beyond the bytes of its packaged programs. Even if those programs agree, the final serialization still needs to agree. The announcement's distinction between package checks and the actual image rebuild follows that composition problem.

Substitution would answer a different question

The rebuild started from a fresh VirtualBox appliance running NixOS 20.03. The report describes increasing its available resources and disk capacity before performing the work. That supplied another environment in which to execute the build rather than merely inspect the published output.

The commands disable substitution with --option substitute false. The report explicitly explains that this forces the relevant work to happen locally instead of fetching the binary cache's result. Without that distinction, a request for an output could simply return the artifact being checked.

This is a central difference between efficient realization and independent verification. A cache hit is often exactly what a normal package installation wants. A reproducer needs another execution of the relevant build steps so that agreement is evidence about the computation, rather than evidence that two clients downloaded the same file.

The report also rebuilds packages needed during image construction that do not remain inside the final ISO. That broadens the computation being repeated. Image-building tools can influence the result even when users will never find those tools on the installation medium.

The procedure pins revision metadata as well as source. The release jobset accepts a Nixpkgs source argument containing fields used in the release configuration. Supplying the reported metadata makes the reconstruction correspond to the identified build context instead of assuming that a source checkout alone supplies every value used by the release job.

Workarounds remain part of the reported procedure

The announcement publishes several manual workarounds rather than presenting the result as an untouched one-command rebuild. Its recipe includes a /dev/kvm workaround and obtaining a suitable Nix version before starting the main image build. It links the corresponding issues so that readers can identify those prerequisites.

Another workaround adjusts timestamps and permissions on several generated files in the store, including files associated with netgroup and mdadm configuration. The procedure then removes the generated filesystem image and ISO outputs and rebuilds them. Those interventions are material to interpreting what the reported success establishes.

The result is therefore a successful independent comparison under the documented procedure. It is not evidence that an arbitrary fresh invocation without those steps already reproduces the image. Removing the workarounds is explicitly among the report's proposed next tasks.

That qualification does not erase the final agreement. It identifies which parts of the process still need to move from manual correction into reproducible build behavior. Publishing the interventions gives another contributor enough context to investigate the remaining differences.

I find that level of disclosure important for an infrastructure claim. A byte match with a visible procedure is useful evidence. Hiding the manual changes would make it much harder to judge which parts of the build are already dependable and which still require repair.

The bootstrap environment remains trusted

The report acknowledges that its starting appliance and downloaded Git package remain part of the trust base. If either contained a sufficiently elaborate backdoor, rebuilding later packages would not necessarily remove that influence. Independent rebuilding is not equivalent to reconstructing every executable from a minimal audited bootstrap.

That is a different boundary from the binary-cache boundary. Disabling substitution prevents ordinary use of cached outputs during the rebuild. It does not remove the executable tools already needed to obtain source and begin executing the build process.

The authors identify a fully bootstrapped starting system as a stronger goal and link ongoing work in that area. Their present claim remains narrower. The comparison gives confidence that the identified ISO can be reproduced from the stated environment, with the documented starting components still trusted.

This matters when explaining supply-chain benefits. Independent agreement can expose differences introduced in one build pipeline. It does not prove that the shared source is free of malicious code, or that two environments cannot share a compromised ancestor. Those questions require additional evidence beyond matching the final bytes.

Repeated verification needs shared evidence

The announcement treats a single successful ISO rebuild as a milestone and calls for infrastructure to repeat independent rebuilding regularly. That next step follows directly from the reported history of regressions. A property demonstrated for one revision can be lost as source and tools change.

It also proposes tools for sharing and consuming build attestations, with Trustix given as an example. Another builder's result becomes more useful when consumers can connect it to an artifact identity and a stated build procedure. Otherwise the evidence can remain an isolated report that is difficult to incorporate into distribution decisions.

The distinction also affects what should be retained from this attempt. The source revision identifies the expressions, while the selected target identifies the image under test. Revision metadata and the list of interventions explain further inputs to the comparison. A report preserving only the sentence that the ISO matched would discard information needed to distinguish a repeated verification of this result from a different build that happened to use the same project name.

The immediate achievement is the complete minimal ISO comparison, including locally rebuilt build-time dependencies. Its published recipe also identifies the current limits, especially the manual metadata corrections and trusted bootstrap environment. Those details give future verification work a specific artifact and procedure to repeat, while preserving the distinction between declared inputs and independently observed output agreement.