Let me give you the simplest example, when builds are reproducible you don't need package repositories, you need build caches.

All the problems with maintaining a repository (save bandwidth) evaporate.

The type of reproducibility is different here. What you mention is possible via a stable compiler ABI already. However one needs to keep the source code the same. Without a stable compiler ABI, you may or may not fix it depending on what the compiler does.

The goal of reproducible builds is removing sources of environment-dependent behavior at the build level instead of the compiler level. So given all the same dependencies and same build commands your binaries should match wherever and whenever you compile them. The distros and software developers also made a huge effort to remove any kind of environment-dependent commands.

Different distros still have differences in the build commands they issue and the set of dependencies they enable. The space to cache each individual possible output would be enormous and impractical. So you would still need repositories.

https://discourse.nixos.org/t/the-nixos-foundations-call-to-...

It is absolutely better to remove build entropy at the source code stage, but until all software is written that way there are a few build-environment tricks we can use along the way.

Meanwhile I enjoy setting up my own GNU Guile projects with a Makefile that sets up a reproducible Guix shell in which my project is run, so that I get the same result on various devices, only needing to issue a single easily memorized or discoverable Makefile target call. Most developers I met don't know how to set something like this up. Provided no one messes with guix package manager commits and guix infrastructure still exists, my projects will run in 10y just like they do today, with reproducible result. Neat.

Recently I have taken some time to have this for Ocaml as well. Took some asking on the mailing list, but now works. No need to have anything installed prior to running the Makefile target other than Make and Guix package manager.

And I did. He was a developer of a purported secure messaging app. The question that changed his mind was: "How are your users, who surely audited your sources and found no trojans hiding there, going to know that you are not distributing trojaned official binary builds?"

Edit: Worth looking at https://github.com/numtide/devshell

I've been using Gentoo for the past few weeks and this was my thought. There are so many ways to compile packages depending on your needs. It is practical to make binary sets for a few common configurations that are good enough for most people for each distro, though.

(Installing and using Gentoo has been an incredible learning experience. You have to go into it with the desire to take long tangents filling the gaps in your knowledge re: shared libraries, kernel modules, your init system of choice, gcc, your windowing system of choice, bootloaders, bash, etc. I feel like I've made more of a quantum leap in my Linux skills the past month than I have in years, and it's been quite fun and rewarding.)

> Different distros still have differences in the build commands they issue and the set of dependencies they enable.

Would it even make sense in theory for this not to be the case? What is a Linux distro but a set of programs, libraries, and environment choices chosen to be run on the Linux kernel?

Seems like Yocto would make the base for a good general purpose desktop distro (if there is not one out there already.)

OE recipe-grade concision! This summary belongs in YP docs, wikipedia and LLM IDE warnings.

Stagex + Yocto would be fully reproducible from a small seed.

> Yocto would make the base for a good general purpose desktop distro

YP has been working on a public binary reference cache/distro.

1. If the deps are also themselves reproducible then you refer to a fixed point version of them and (at least for nix) the package manager works out the rest.

2. Signatures are a trust mechanism, if a cache feeds you bad data in response to a query then that's absolutely an issue, but since there can be multiple caches (or your own local spot-checks) it becomes easier to detect if a cache is returning bad data. A hyper-targetted attack would still get you unless you decide to manually build certain packages, but that's no different than existing repos.

Manually building might sound impractical but it doesn't actually take that long, probably less than a day for a desktop environment, which might acceptable in a high-trust environment if amortized. I should add that the process is fully automatic, it just takes longer than using a cache.

3. Moderation I don't have a good answer to, anyone can run an apt server, or publish a flake.nix file to a repo. Some would say it is censorship resistant.

It certainly doesn't change the nature of packaging in any real way in that case.

[1] https://salsa.debian.org/reproducible-builds/reproducible-pr... [2] https://fosdem.org/2025/schedule/event/fosdem-2025-6479-a-ta...

Regarding the reproducible bootstrapping problem, what is your project's policy on building from binary sources? For instance, Zig is written in zig and bootstraps from a binary wasm file which is translated to C: https://github.com/ziglang/zig/tree/master/stage1

Golang has an even more complicated bootstrapping procedure requiring to build each successive version of the compiler to get to the most recent version.

https://bootstrappable.org/ https://lwn.net/Articles/983340/

To solve the need for trusted compilers (aka bootstrap from binary seeds) you're probably interested in https://bootstrappable.org/ and https://codeberg.org/stagex/stagex.

To solve the need for trusted source code there isn't really any solution besides "have people publicly document the source code they have read", like https://github.com/crev-dev/cargo-crev does. Often people ask "how do I know whose reviews to trust", but in reality there's a scarcity of reviews even if you're willing to trust literally anybody. There aren't really any incentives for people to make them, capitalism is failing us on that front and big companies don't want to publicly talk about the source code they have and haven't read either.

But I still do not understand the point of "reproducible builds". I know what they are, but to me the amount of work involved outweighs the benefit.

I even heard NetBSD is also working on "reproducible builds". So maybe I am missing something :)

The main benefit is that you can trust that the resulting binary file being served matches the source code that it's build from. This mostly matters for distros in that they build from a source package repository, but anyone running a mirror could hypothetically replace the package with another (potentially malicious) package, leading users to install malicious tooling. It mainly matters for distros because pretty much every distro out there runs on third party mirrors (often ran by universities, but also just people who want to help) rather than on direct upstream; packages get uploaded to a main server, then mirrors copy from that main server (to reduce network traffic load on the main server). Right now, mirror trust is mostly "we assume you're not gonna be evil, until we get complaints". If the build is reproducible, the software can inherently confirm that the file they're getting is trustworthy, making "getting complaints" much easier to confirm.

It can also speed up the overall building process; if the package source code hasn't changed, you can also always assume that the resulting binary hasn't changed (meaning you can use hashes instead of relying on mtime like make does). Docker build cache works in a somewhat similar way (although docker isn't inherently deterministic).

Devwise, you can also reconstruct a build much easier if it's reproducible; ie. if you've accidentally thrown away the .elf file for debugging, if your build is deterministic, you can just rerun the build and get the same .elf file again.

[0]: While not a problem for Linux distros, in cases where you need a secret to sign an application, reproducible typically means "identical except for the signature" instead. F-Droid uses this for example to figure out if they should use buildserver stuff or the original APKs: https://f-droid.org/docs/Reproducible_Builds/

It was my assumption that a mirror is required to host a build that has a hash conforming to the original. Is that not the case?

Note that mtime still has the advantage of being faster than hashing.

I think the actual main utility is that the process has done a very good job of rooting out several causes of unintentional nondeterminism in the build process. I say unintentional because the two main causes of unreproducibility, by several orders of magnitude, are timestamps being embedded everywhere and absolute paths being embedded everywhere, and those are rather expected. But some of the unreproducibility comes from things like accidental reliance on inodes in file paths (i.e., doing "for file in listdir()" without sorting the results of listdir) or the compiler itself accidentally sorting based on pointer address (which is unreproducible on ASLR systems).

I don’t know whether I’d spend this much work on such an abstract goal, but what reproducibility changes really is quite amazing. It vastly increases trust in published binaries and obviates the need for signing and the security benefit of compiling software yourself.

Not really. Most people still would rely on signatures because they can't be expected to compile everything from scratch just to verify their download is authentic. Moreover even though reproducible builds make verification easier, it still requires someone to sound the alarm. For less popular packages there might be nobody checking any particular build is backdoored, because most people see "reproducible builds" and they assume Somebody Else is doing the reproduction.

you still may not trust the public gobuilds instance. my hope is that people (eg software projects themselves, or distros, or other kinds of communities) will run & use their own gobuild instances and verify their builds against the public gobuilds service. win-win: gives them assurance their builds are really reproducible, and builds trust in the public gobuilds (keeping it honest, if someone sees a hash mismatch, they will speak up).

i usually don't get much enthusiasm for it though. (:

Given the increasing likelihood of supply chain attacks, isn’t this a very prudent precaution?

If I'm understanding correctly, the malicious code was introduced as part of the test code, so no matter who compiled it, they'd get a binary with the same (malicious) functionality. Heck, it might even have been reproducibly malicious.

The real crazy part was that it was modifying the functionality of sshd at runtime, allowing the attacker to log into any system.

Reproducibility of either sshd or xz wouldn't have stopped this attack.

That's my reading of https://research.swtch.com/xz-script.

Yeah, `bazel run test:...` would have access to the test files, but `bazel build xz:executable` would not (by default) be able to pull in extra shenanigans from the test files (and I think there's generally linting and formatting rules required by default with `BUILD.bazel` files, reducing another sneak-vectors)

For that we'd need some sort of source code reviewing effort like https://github.com/crev-dev/cargo-crev implements. I've started whatsrc.org to keep track of the source code inputs we're putting into our computers (that would benefit from reviews), but the conclusion is also somewhat "it's too much".

https://bootstrappable.org/ https://lwn.net/Articles/983340/