Live data from Hacker News

Debian must ship reproducible packages

lists.debian.org

81–90 of 178 posts

Re: Debian must ship reproducible packages

#81
post #50

Earlier quoted context omitted.

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…

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.

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.

Re: Debian must ship reproducible packages

#83
post #49

Earlier quoted context omitted.

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…

” 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?

(Not OP, but...) I still fail to see the current value in confirming that a reproducing builder also included the same compromised dependency that I did when I built it. I understand that reproducible builds are guarding against dynamic attacks within build infrastructure. However I just don't see those happening. Compromised source dependencies are a 100x more common problem.

Re: Debian must ship reproducible packages

#84

Earlier quoted context omitted.

Has there been a single publicly known attack that would have been prevented by this?

Why should it only be valuable if the effects were to be publicly known? There are plenty of places in industrial computing where reproducible builds have prevented subterfuge within the organizations themselves. Injecting binaries to do inf-/exfiltration is a long-standing industrial espionage activity which is of immense value to all users of the operating system - not just the consumer users.

My magic beans have prevented thousands of tiger attacks in top secret underground moon bases, never you mind that there's no way for me to actually prove this.

There's a certain irony in pushing for verifiable builds with completely unverifiable claims.

I've worked at several of the biggest targets for espionage, industrial or otherwise, and to the best of my knowledge, the only thing that's ever been discovered by their reproducible build efforts has been failing hardware on build reproducers

Re: Debian must ship reproducible packages

#85
What people really don't understand about reproducible builds is that they're not a guarantee that there's no backdoor.

They're a guarantee that if there's a backdoor, it's reproducible 100% of the time.

This is a godsend for white hats fighting the good fight.

And, as a side note, it's strongarming vs the bad guys: "Would be too bad if we could reproduce your shiny exploit 100% of the time wouldn't it!?".

Note that we should go further (but it's a bit orthogonal to reproducible builds): builds of the final binary/package should happen by first entirely discarding all files not necessary for the final build (like all test cases and all test assets). The build should literally happen in an environment that gets rid of those (after, of course, having test in another environment that all tests cases succeed): if I'm not mistaken get rid of test assets would have stopped Jia Tan's XZ backdoor attempt dead in its track (for example). Because IIRC there were binary data part of the backdoor hidden in some asset only used by test cases.

P.S: as a bonus they also allow to detect bit-flips (I'm not saying there aren't other ways to detect bit-flips: what I'm saying is that if you have deterministic builds anyway and something doesn't reproduce correctly due to a flipped-bit, it's going to be noticed).

Re: Debian must ship reproducible packages

#86

Why the fuck does that site break the back button? DO NOT do that.

since there is no other way to reach you please allow me to use this off topic message to let you know that there is a response to your comments on the gnupg discussion from two weeks ago.

Re: Debian must ship reproducible packages

#87
post #32

Good thing. NetBSD has fully reproductible build since 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

While we are bragging, stagex was the first to hit 100% full source bootstrapped deterministic and hermetic builds last year and the first to make multiple signed reproductions by different maintainers on their own hardware mandatory for every release. Debian has come along way, but when Debian says reproducible they mean they grab third party binaries to build theirs. When we say reproducible we mean 100% bootstrapp…

This!

Unfortunately, the term “reproducible” can be interpreted in many ways because there is no strict and complete definition. People and projects bend it to their liking.

Your approach is correct.

https://www.bootstrappable.org/

Re: Debian must ship reproducible packages

#88
post #31

This is a huge achievement for Debian and the free software world. It took a while though until this was understood. In 2007 when pointing out on debian-devel that this is needed, I was still told what huge waste of time this would be. And indeed it took a huge amount of work by many people to get there, but it is well worth it.

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…

Is the "Jia Tan" XZ Utils compromise not a good example? That relied on code snuck into a release that was not in source.

(It was caught before being promoted into a stable Debian release, yes, but this sort of relied on a happy accident, too close for comfort)

Re: Debian must ship reproducible packages

#90

Earlier quoted context omitted.

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…

Is the "Jia Tan" XZ Utils compromise not a good example? That relied on code snuck into a release that was not in source. (It was caught before being promoted into a stable Debian release, yes, but this sort of relied on a happy accident, too close for comfort)

The xz hack was still reproducible, because it was included in the distribution archive which did not match the upstream source -- even then, it was so obfuscated it likely would have gone unnoticed, but nevertheless it only lived in the uploaded tarball and not in the repo. Reproducibility is a good thing, but the next step is build provenance.

Still, lots of good non-security benefits to reproducible builds too.

Post reply on HN