Live data from Hacker News

Debian must ship reproducible packages

lists.debian.org

161–170 of 178 posts

Re: Debian must ship reproducible packages

#161
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?

Sure. The site appears to be a bunch of warm-fuzzies that could apply to almost any other measure you take, it's nothing specific to reproducible builds. As the original poster said "There was no bug or attack on Debian since 2007 that reproducible packages would prevent". In fact, it could be argued that reproducible builds lead to a reduction in security, not an improvement: They give an attacker an exact fixed memory layout for all of the binaries, so if you develop something like a ROP exploit for a copy on your local system you know that exploit will work on every other system as well because the binary layout is identical. It's a perfect monoculture where everything is vulnerable to the same exploit. It seems to have been something created by geeks to impress other geeks, without any considerations for whether it has any actual benefit or not.

Re: Debian must ship reproducible packages

#162

Earlier quoted context omitted.

Yes, making sure build timestamps are reproducible isn't a security win. What is a win is that two independent parties can run the same build, and get the same binaries. This is important because it removes trust from builders: anyone can verify their output. It just so happens that unimportant things like build versions impede that.

Anyone can verify the actual code in the binary matches even if some bytes within the binary file itself are different. The verification routine doesn't have to be a basic bit for bit equality test.

For sure.

This has been the status quo in Debian for a while now. You can build, and use diffoscope to audit the differences.

It's a stronger security property to have bit-for-bit reproducibilty, and it looks like Debian are ready to commit to it.

Re: Debian must ship reproducible packages

#163
post #49

Earlier quoted context omitted.

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

Sure. The site appears to be a bunch of warm-fuzzies that could apply to almost any other measure you take, it's nothing specific to reproducible builds. As the original poster said "There was no bug or attack on Debian since 2007 that reproducible packages would prevent". In fact, it could be argued that reproducible builds lead to a reduction in security, not an improvement: They give an attacker an exact fixed mem…

This comment is misinformed. Non-deterministic builds would also result in one tarball redistributed to all distro users. The ROP exploits don't work because of ASLR.

Re: Debian must ship reproducible packages

#164
post #79

Earlier quoted context omitted.

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.

You’re not thinking like an industrial user but rather as a consumer. Maybe you should extend your scope a little bit.

Industry is learning - often the hard way that out of date software is only acceptable if the device is not connected to a network at all. Even government labs with a separate top secret network that isn't supposed to be connected to anything else get hacked from the internet.

Not that you are wrong, industry keeps thinking they can make themselves immune and so long term reproducibility is useful, but I submit they are wrong.

Re: Debian must ship reproducible packages

#165

Earlier quoted context omitted.

It allows verifying that the binaries actually match the source, which is extremely valuable.

Bit for bit matching is not required for that.

It makes it much simpler and more robust though. Also, it allows for content addressing a la Nix, among other benefits.

Re: Debian must ship reproducible packages

#166

Earlier quoted context omitted.

A warning is sufficient. Old tech should continue to work, for preservation and archival reasons.

I've long ago realized that archival needs to be a separate task left to archivists and archive systems. If you take it into account when designing a live system it's liable to seriously compromise your system design. Say you're making a chat app - you wouldn't incorporate a delete feature, and you might be tempted to use some kind of blockchain to prove all messages were delivered without gaps. But if you ignore arc…

That depends on your user base. If your group of target users includes professional, corporate, or governmental use, then you absolutely need to build in signing and archival for legal reasons. If your users include people who may only connect occasionally or with flaky connections, then you need a robust way to ensure that messages are held for delivery and that all messages are delivered in order. Basic chat (without delivery guarantees or archival) is already solved by IRC, long ago.

Re: Debian must ship reproducible packages

#167
post #79

Earlier quoted context omitted.

Those problems need to be solved as well.

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.

You probably don’t know how industrial computing works.

Toolchains absolutely need to be maintained with some degree of longevity.

The whole world doesn’t march to your consumer-user beat. Sometimes it functions at industrial-user tempo’s, too ..

Re: Debian must ship reproducible packages

#168

Earlier quoted context omitted.

You’re not thinking like an industrial user but rather as a consumer. Maybe you should extend your scope a little bit.

Industry is learning - often the hard way that out of date software is only acceptable if the device is not connected to a network at all. Even government labs with a separate top secret network that isn't supposed to be connected to anything else get hacked from the internet. Not that you are wrong, industry keeps thinking they can make themselves immune and so long term reproducibility is useful, but I submit they…

Disclaimer: I work in the safety-critical/industrial sector of software.

Literally none of your statements are applicable to that realm, sorry.

Rail operators have long since been operating their air-gapped infrastructure with 99.999% safety results, literally not adhering to any of the policies you claim are endemic to the industry.

Re: Debian must ship reproducible packages

#169
post #98
post #32

Earlier quoted context omitted.

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…

newcomers will always have it much easier. also guix i think also reached this. also, stagex and others probably profited QUITE A LOT from the debian efforts, because they started to go upstream and talking to developers.. just arch linux profited from debian maintainers a decade before that an debian people asking upstream to improve...

Guix did a full source bootstrap first, credit where well due, but it does not apply to their whole tree. E.g haskell is bootstrapped with a binary, qemu includes binary firmware blobs, etc.

Guix is not fully bootstrapped or reproducible.

To your point though, the incomplete efforts of many other distros absolutely accelerated us.

Re: Debian must ship reproducible packages

#170
post #70

Earlier quoted context omitted.

> zero improvement on end-user experience The end-user experience is that now you can host your Debian binaries in caches and CDNs without worrying about supply chain hackers. You can verify that file hashes match the ones on Debian's website and sleep much better at night. If you don't trust Debian's website then you can rebuild yourself and check if Debian has been compromised.

You could already do that since Debian cryptographically signs all its package indexes, and the indexes contain the hash of all packages. The additional guarantee that reproducible builds bring is that you can re-build the packages in your own controlled environment and verify that the resulting package is bit-for-bit identical to what Debian offers.

Cryptographic signatures only protect against MitM (something extremely rare in the real world) and do nothing against compromised Debian infrastructure and supply chains (the real attack vector 99% of the time).

Reproducible builds protect against all attacks.

Post reply on HN