Like some other commenters, I do not understand why using a cached binary isn’t sufficient. Why not use the mold3 binary and build that first, and then cache it and never rebuild it again? I’m guessing it has to do with hermiticity and build provenance guarantees in your distro.
Do you have any reading material that you can share that might help me understand better? Docs for the distro, or an issue tracker I can search through?
In short, the entire distro is always built in one-shot at any given commit, and we can only rely on cached binaries from a past release if they or nothing in their supply chains changed. Given rustc depends on almost everything, mold3 would be built far too late to be useful for the most expensive build in the whole tree, which is rust.
Recursive dependencies would break our threat model, so we cannot use any rust tools to bootstrap rust. We bootstrap rust from llvm which we bootstrap from gcc which we bootstrap from tinycc which we bootstrap from M2Planet and so on back to 186 bytes of machine code.
Anyone getting a rust package from stagex must be able to build the entire tree up until that package and get the same hash, with no binary dependencies, thus removing any trust in maintainers.
If you can boostrap one version of stagex (so that its mold is trustworthy), I don't see why you can't use that to build another version of stagex.
As you say, you can rely on the cached binary because nothing in the old version's supply chain would change; it is pinned, and as long as you can build that, everything is fine.
The threat model is trust no single person or computer.
In order for you to not have to trust us, you must clone our repo, of only source code, and build from zero to our released binary hashes. The shorter we can make the time for that to be possible, the more people we can convince to do it and ideally sign and publish their matching hashes. The more people we convince to do it, the less risk of us as maintainers being able add a backdoor without anyone noticing.
Mold was a tool to shave hours off the time most people have to spend doing a from-scratch verification. Forcing them to build a whole tree to get to rust to et to mold3, to then use that to build the whole tree a second time, would directly work against the goal of minimizing full tree verification time.
> In order for you to not have to trust us, you must clone our repo, of only source code
> rust from llvm which we bootstrap from gcc which we bootstrap from tinycc which we bootstrap from M2Planet and so on back to 186 bytes of machine code.
While the effort is laudable, the fact that these are built from source is not enabling me to verify them. Rust, LLVM, gcc, tinycc, all the way back to that 186 seed are prohibitively large to verify.
I'm not even in a position to verify the delta to these projects over a single day. I'm having to trust _someone_, many someones.
An operating system distribution owns specifically the compiling and distribution links of the supply chain. It is our job to prove we produce artifacts accurately and faithfully from upstream source code without giving ourselves any ability to tamper with the sources or the resulting artifacts.
Our specific responsibility is to limit the number of people users have to trust to only the actual authors of the software they are installing.
I wonder if a rust-to-c tool would help you, your mold2 would just be the cached result of that. Would that C code still be treated as a binary dependency since it would not be very human readable?
How about a rust-to-wasm process, you store the wasm binary, but have a human readable wasm interpreter that only implements enough for mold to work? Would that be trusty enough?
If a rust-to-c tool could fully handle this automatically, and said tool only depended on an early language like go or c, that would be very useful for many problems including this one.
Self inflicted because we want to protect as many people as possible from supply chain attacks. That is a very real engineering problem we have to solve that extremely high risk end users of our work depend on.
Most popular Linux distros take a position of hoping and praying supply chain attacks do not target them. I am not convinced this will go well for them in the post AI world, but hey, I also hope I am wrong.
There are plenty of other points in the design space here. For example, I think once a sufficient number of people have built a binary and verified that it is the same hash (publishing the hashes to an irrevocable transparency log), caching those binaries doesn't increase the supply chain surface. The point you have chosen is quite out there, and it isn't reasonable to expect others to conform to it, and it certainly isn't reasonable to say that Rust isn't the right choice for a project because it negatively impacts you.
> caching those binaries doesn't increase the supply chain surface.
Okay, but what if all the signers are people that a new user does not know? Who is to say all those signatures are not a bunch of made up AI identities?
This is why we make it trivial for anyone to clone our tree and build from zero and get the same result at any release with no required binaries of any kind anyone has to verify the provenance of. This is called full source bootstrapping. The cheaper we make that, the more people that will do it and the higher the chances users will see a signature from someone they personally trust.
Your arguments sound reasonable to me. It’s a bit worrying to hear people playing make-believe about security.
I’ve been told “no one thinks a programming language always makes software safer” but the comments here suggest many actually do believe just that. The problem you’ve defined is a threat to the “my language is a silver bullet” belief.
I think you might be fundamentally misunderstanding distro maintainers' role in the ecosystem. Your job is not to question your upstreams' development practices or technologies used, beyond the basics like it being FOSS -- it is to adapt to them.
That seems rather one-sided to me. In a healthy FOSS ecosystem, shouldn't the upstream developers and distro maintainers be peers, with the upstream developers respecting the needs and values of the distro maintainers, rather than unilaterally insisting that the distro maintainers adapt?
I have sympathy for overburdened distro maintainers who feel that recent trends in upstream development practices are going in the wrong direction, as expressed in this blog post earlier this year: https://blogs.gentoo.org/mgorny/2026/03/07/money-isnt-going-...
Edit to add: And yet, I would be very reluctant to give up the safety of Rust to go back to C or C++. I don't know what the answer to that one is, but I don't think it's to tell the distro maintainers that their role (decided by whom?) is to adapt to what upstream developers are doing.
Upstreams naturally know a lot less about supply chain security than we do as that is our core expertise. We leave deciding what features are correct for their users to them, and handle supply chain integrity.
Often having to make lots of small patches to preserve upstream functionality while fixing their obvious security and determinism bugs. Or we have to ignore autogenned code and figure out bootstrapping ourselves. Many upstreams just put binaries in their source code and call it reproducible.
For instance, XZ published a malicious hand-packed archive of their code that many distros use because it has all the auto-generated code already. We totally ignored that archive and pulled the code that was actually reviewed, and ran autogen ourselves. In doing so we were never impacted by the XZ attack.
We are obligated to do anything we can to protect our users, even if most thing doing so is paranoid.
Do you have any reading material that you can share that might help me understand better? Docs for the distro, or an issue tracker I can search through?