Hacker News Reader

Comment by taviso | Hacker News Reader

> As a developer, it would be quite reassuring to build my binary (which I already do for testing) and compare the hash with the one from the CI server to confirm nothing has been tampered with.

That makes sense! However, this is not a good argument for reproducible builds, because you can already do that today.

You already have to build a trusted binary locally for testing right? You're dreaming of being able to compare that against the untrusted binary so that you can make sure it's a trusted binary too - but you already have a trusted binary!

Okay - but it's a hassle, you don't want to have to do that, right? Too bad - reproducible builds only work if someone reproduces them. You're still going to have to replicate it somewhere you trust, so you gained practically nothing.

View on HN

With the reproducible build, you can start using the untrusted binary while you are still building your trusted one.

You can also have ten people on the internet verify the untrusted binary. With signatures, adding more people doesn't help.

> With the reproducible build, you can start using the untrusted binary while you are still building your trusted one.

That's not how it works, you have to reproduce it before it becomes trusted.

> You can also have ten people on the internet verify the untrusted binary.

Sure, then we have to build a complex consensus system that introduces a bunch of unsolved problems. My opinion is that this just isn't worth it, there is practically nothing to gain and it's really really hard.

> That's not how it works, you have to reproduce it before it becomes trusted.

Eh, there's stuff you can do with software before you trust it. Eg you can start pressing the CDs or distributing the data to your servers. Just don't execute it, yet.

> Sure, then we have to build a complex consensus system that introduces a bunch of unsolved problems. My opinion is that this just isn't worth it, there is practically nothing to gain and it's really really hard.

It's the same informal system that keeps eg debian or the Linux kernel secure currently:

People don't do kernel reviews themselves. They just use the official kernel, and when someone finds a bug (or spots otherwise bad code), they notify the community.

Similar with reproducible builds: most normal people will just use the builds from their distro's server, but independent people can do 'reviews' by running builds.

If ever a build doesn't reproduce, that'll be a loud failure. People will complain and investigate.

Reproducible builds in this scenario don't protect you from untrusted code upfront, but they make sure you'll know when you have been attacked.

> People don't do kernel reviews themselves. They just use the official kernel, and when someone finds a bug (or spots otherwise bad code), they notify the community.

There's a big difference here. When a vulnerability is found in the Linux kernel, that doesn't mean that you were compromised.

If a build was found to be malicious, then you definitely were compromised and it's little solace that it was discovered after the fact. This is why package managers check the deb/rpm signature before installing the software, not after.

Well, you'd still check the signature, to make sure you have the same build that the debian repository has.

This is just an additional check that the debian repository has sane builds.

(If someone mucks around with the debian repositories but you aren't the target, you might or might not be under attack.)

Reply on news.ycombinator.com