Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian must ship reproducible packages

lists.debian.org

Post reply on HN
Print view View original

121–130 of 178 posts

Re: Debian must ship reproducible packages

#121

Post by yjftsjthsd-h »

PunchyHamster wrote: post #43
aborsy wrote: post #40

Earlier quoted context omitted.

There was perhaps no detected bug or attack. There have most likely been bugs or attacks that reproducible builds would have prevented.

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.

> as Ubuntu package will have same files structured exactly same way as Debian one.

As opposed to what? If Ubuntu uses the same source, of course they get the same binaries. And if Ubuntu applies patches, they'll get something different. And that's still true.

Re: Debian must ship reproducible packages

#122

Post by saghm »

PunchyHamster wrote: post #115
sgc wrote: post #81

Earlier quoted context omitted.

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 ef…

I think that project is called Ubuntu.

Building Ubuntu does not produce identical binaries to Debian, so no, that's not what they're asking for

Re: Debian must ship reproducible packages

#123

Post by uecker »

jcranmer wrote: post #109
benregenspan wrote: post #88

Earlier quoted context omitted.

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 utils compromise is a very good example... of why reproducible packages doesn't actually solve anything security-wise! The backdoor relied first on a difference between building a package in a packaging environment versus building the package on your own. And also, it relied on the very common practice of checking in unreviewable artifacts into the source tree (e.g., the configure script, malicious binary test…

An attack would be far easier without reproducible packages. One could upload a compromised binary to debian by becoming a debian developer, blackmail a debian developer to so, or compromise the computer of a debian developer or the distribution.

At the time of xz attack, the package was already reproducible.

Re: Debian must ship reproducible packages

#124

Post by jgneff »

I'm so happy to see this change. I got involved with reproducible builds in 2021 after reading in horror about the SolarWinds attack. [1]

I think Magnus Ihse Bursie said it best while working on reproducible builds of OpenJDK: "If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one." [2]

[1] https://www.linux.com/news/preventing-supply-chain-attacks-l...

[2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

Re: Debian must ship reproducible packages

#125

Post by uecker »

PunchyHamster wrote: post #113
savolai wrote: 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?

I know why they are useful. I am arguing they are waste of time for effort involved. Forcing devs to use hardware keys to sign commits/CI requests would be actual security improvement, thwarting many supply chain attacks that only worked coz the attacker got to developer credentials. Hardware keys at least have option to make some operations require physically pressing the key so there is chance developer will notice…

A hardware key does not help if the developer's machine is compromised, as there is no change to understand what is signed anymore, or do you think the hardware key will show all the source code on its little display before signing?

With reproducible builds, you do not need to trust that the system that build the binary was not compromised, because this would be detected immediately.

Source compromises are still an issue, but there is a much bigger change that they are detected. Also if there is a compromise, reproducible builds allow you to later track it to the source. For an infected binary it is much more difficult to understand how it got there and what else might be compromised.

Re: Debian must ship reproducible packages

#126

Post by charcircuit »

Hendrikto wrote: post #65
charcircuit wrote: post #34

So much time has been wasted on reproducible builds which could have better spent on securing more important parts of Debian. Practically minor changes like a build timestamp being different is not an issue.

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

Bit for bit matching is not required for that.

Re: Debian must ship reproducible packages

#127

Post by ckastner »

PunchyHamster wrote: post #117
ckastner wrote: post #100

Earlier quoted context omitted.

> There was no bug or attack on Debian since 2007 that reproducible packages would prevent. I'm reading this as a suggestion that the reproducible builds effort was an ineffective deterrent. However, note that your observation could also be explained by the opposite: the reproducible builds effort was an effective deterrent, so nobody bothered with attempts. > And it just ups the the contribution barrier to Debian hi…

> However, note that your observation could also be explained by the opposite: the reproducible builds effort was an effective deterrent, so nobody bothered with attempts. There was no attack that reproducible builds would help protect from before 2007 either. > Until yesterday, the package just got flagged in the tracker, and you could either ignore it, or fix it yourself, or the kind people behind the reproducible…

> They are not. They are best practices if you want reproducible builds.

Or if you're writing a test suite, and you want failing test results to be actionable.

Or you have any other type of behavior that you'd like to reproduce somehow.

One of the first things app developers ask for in bug/issue templates are the steps to reproduce something. I wonder why you'd think that they would suddenly be opposed to the concept when thinking of a build peocess.

Re: Debian must ship reproducible packages

#128

Post by charcircuit »

farfatched wrote: post #78
charcircuit wrote: post #34

So much time has been wasted on reproducible builds which could have better spent on securing more important parts of Debian. Practically minor changes like a build timestamp being different is not an issue.

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.

Re: Debian must ship reproducible packages

#129

Post by charcircuit »

deknos wrote: post #101
charcircuit wrote: post #34

So much time has been wasted on reproducible builds which could have better spent on securing more important parts of Debian. Practically minor changes like a build timestamp being different is not an issue.

you are free to provide patches instead of bitching.

And Debian is able to offer me a few million dollars yearly to help fix their security situation.
Post reply on HN