Hacker News Reader

Comment by lrvick | Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com