Hacker News Reader

Comment by jlarocco | Hacker News Reader

Except for the first one, the last three are great examples of why I don't care about 100% binary reproducible builds as an end user.

Knowing when something was built is more valuable to me than a reproducible build. Seems like a fad triumphing over common sense.

View on HN

Reproducible builds allows for better auditing which makes it more difficult for malicious maintainers to plug backdoors into systems.

What's the relevance of knowing when something was built if you can check the source version and rebuild it yourself in the exact same way? If the build is reproducible it's merely a cache. You could potentially recompile it every time you try to execute the command and you'd get the exact same thing.

Users often don't care about things until they become a problem. For example, most users don't care how their password is stored on a server... until it gets compromised. Also, timestamps in output usually indicate source code age, not build date. I have a package with '2015' in the version but it was built in 2018.

That's a condescending non-answer.

We're not talking about passwords in a database, we're talking about reproducible builds. I already trust Debian, so it's irrelevant to me, as a user, if their builds are 100% reproducible. Can you explain why I should feel differently?

Although I don't think it's a valuable thing to spend time on, it's not my time, so I honestly don't care too much.

From an end user point of view, probably the most important thing it allows Debian developers to do is verify that the binary packages they are shipping are the packages they intended to ship. You trust them, they have to trust their tools... so they're making sure their tools tell them about yet another situation when something might have gone wrong. (it could be something innocent or malicious, but without the tooling, they might not even be aware of the issue)

It doesn't: there can still be backdoors or compiler errors before the hash of the binary. That's why DO-178C certification requires proof of source-to-binary equivalence. It's also why CompCert and CakeML were built. Stopping backdoors requires doing that with independent review for requirements, design specs, security policy, and implementation with them all corresponding.

People concerned about this stuff are putting the least effort into what causes the most failures. Reproducible builds are a distraction if what's reproducible is 0-day-ridden software whose safety/security checks might have been removed by buggy, black-box compiler.

You are right that this isn't the be-all, end-all but is merely one of the pieces needed. I was trying to give a layperson's reason for caring (i.e. what was being asked) which often involves oversimplifying things.

Oh, you explaining it is a nice thing to do. I was just showing what was actually necessary to meet the intended goal since that's my field. I learned a lot of the problems from people like Myers who wrote the book on subversion back in 1980. Current approaches still aren't as thorough as what they were doing in the 1970's-1980's.

https://csrc.nist.gov/csrc/media/publications/conference-pap...

If it's about repos, I recommend David A. Wheeler's page on SCM security since following it eliminates most of the risks.

https://dwheeler.com/essays/scm-security.html

Knowing when something was built is more useful than having better verification of exactly what code went in?

Besides, it's a deterministic build. You can use a lookup table with the hash to find out exactly what revision it is.

If the build is reproducible, why does it matter when it was built?

Knowing the build was reproducible tells me nothing of value.

Knowing the timestamp of when it was built, or the source was downloaded tells me roughly how old the package is, which can be useful for a variety of reasons.

>Knowing the build was reproducible tells me nothing of value.

It does. It proves that the given package was produced by the given source code. However, you can keep the timestamp as well! One of the goals of reproducible builds is to record values like this so it can be replayed later at a future point in time. This is done by the BUILDINFO format.

https://reproducible-builds.org/docs/recording/

> Knowing the build was reproducible tells me nothing of value. It means you can uniquely address what you wanted by what you got (and vice versa). This makes storing and retrieving things much easier, scalable and secure. It also makes it much easier to ensure that you got what you wanted, and someone else did too, on their machine.

I can do a build off of year old code.

Would you rather you get a timestamp embedded that tells you it was built today, or take the hash and be able to find the exact revision.

You don't care about the build date, you care about the release date, which is specifically what debian is trying to achieve with SOURCE_DATE_EPOCH.

Do you care when the build was made or from when the code build into it is? The former is a problem for reproducible builds, the latter is possible.

Reply on news.ycombinator.com