upvote
There was no bug or attack on Debian since 2007 that reproducible packages would prevent.

"Well worth it" is not correct. And it just ups the the contribution barrier to Debian higher, I already heard a lot of people complaining that contributing to Debian is hard and while in past I defended it by "they need all the checks and bounds to make sure packages play with eachother nicely", this is just step that makes it hard for no reason and little benefit.

reply
” If you are wondering why we are doing this at all, then hopefully the Reproducible Builds website will explain why this is useful.”

https://reproducible-builds.org/

Could you perhaps respond to the argumentation here?

reply
Reproducible builds reduce the need for trusted parties.

Have many organizations produce the binaries independently and post the arifacts.

Once n of m parties agree on the arifact hash, take that as the trusted build.

If every party reaches a different hash then we cannot build consensus.

reply
To move away from organizational dependence, there should be an installable project for debian where I can dedicate some configurable small percentage of my compute when idle to reproducibly building debian components to make a robust verification system, starting with the most critical code.

Obviously, it would be a ton of work to make such a system resistant to gaming by malicious actors (see GNU Guix for useful efforts), but it would provide valuable diversity in architecture and (political or other) control.

It would be even cooler if we could have independent projects that could run on various distros and OS, and build packages for any of them. Having packages for bsd verified on linux and vice-versa with statistical logging (this code has been verified x times on y OSes) would be reassuring.

reply
Reproducible builds are applicable not only to respond to ‘attacks’, a subject you seem to be bikeshedding, but also for other reasons too.

Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go.

Reproducible builds are about longevity as much as they are about security.

Please don’t make bold claims about ‘no reason and little benefit’ while demonstrating ignorance of this hard fact: reproducible builds should have been the norm, in computing, from the get-go.

reply
I longevity is harmed though. Your certs need to expire in a few years we think that your toolchain will not be downloadable.
reply
Those problems need to be solved as well.
reply
I don't think they do, actually. Longevity sounds good, but in reality anything that's old probably has critical security holes and so you shouldn't use it anyway.
reply
It makes shipping backdoors a whole lot harder, yes.
reply
Hmm, it prevents Trojan binaries which is a small subset of backdoor IMHO.

Defense in depth obviously is a good thing

reply
There was perhaps no detected bug or attack. There have most likely been bugs or attacks that reproducible builds would have prevented.
reply
And you base it on what exactly ? It's "just" making sure the build process is always ordered.

If anything it will make attacker's job easier, as Ubuntu package will have same files structured exactly same way as Debian one.

reply