undefined | Better HN

0 pointsckastner1mo ago0 comments

> 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 higher

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 builds effort supplied a patch themselves.

Now, you can no longer ignore it. But fixes are often trivial. Use a (stable) timestamp provided by the build, seed RNGs with some constant (instead of eg: time), etc. These are best practices anyway.

0 comments

5 comments · 2 top-level

PunchyHamster1mo ago· 3 in thread

> 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 builds effort supplied a patch themselves.

> Now, you can no longer ignore it. But fixes are often trivial. Use a (stable) timestamp provided by the build, seed RNGs with some constant (instead of eg: time), etc.

that's the entirety of the problem. App developers don't want to be package experts or build experts.

> These are best practices anyway.

They are not. They are best practices if you want reproducible builds. They are entirely useless waste of time if you don't care.

yjftsjthsd-h1mo ago

> that's the entirety of the problem. App developers don't want to be package experts or build experts.

App developers and Debian package maintainers are already separate groups.

ckastnerOP1mo ago

> 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.

PunchyHamster1mo ago

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

The class of bugs would be extremely small as the stuff that makes build hard to reproduce are 99% of the time stuff irrelevant to runtime like some build time embedded in binary, some file metadata having different timestamp, or maybe linker putting stuff in a bit different order.

> 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.

I think you will find amount of people that had problems reproducing because of non-100% exact build is vanishingly small, possibly non-existent.

And that is because if you get package version and want to reproduce it, you get the package, install it and try to reproduce it. The package WILL be 100% the same as the one you got in bug report because you both downloaded the same artifact from same mirror network. You don't need reproducibility to get same binary to reproduce bug

Atotalnoob1mo ago

That’s a big logical fallacy, I’m not sure if that’s what you want to go with

j / k navigate · click thread line to collapse