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

You don’t need reproducible builds

blog.cmpxchg8b.com

Post reply on HN
Print view View original

101–110 of 179 posts

Re: You don’t need reproducible builds

#101

Post by mamon »

7786655 wrote: post #81
sschueller wrote: post #27

Yes you do. How else can you trust an open source bitcoin client in the play store is the same version published on github?

The whole point of the article is that in order to check if the play store version is the same, you have to download the github version and build it from source. At that point, you might as well throw away the play store binary and use the one you just built.

Yes, but it takes just one person to download github source and build it to verify that a binary available in the play store is safe so that the other 1,999,999,999 Android users don't have to.

Re: You don’t need reproducible builds

#102

Post by hinkley »

Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

Scientific method debugging as well.

If the new version is busted, I want to rebuild the same output only changing the compiler, or package manager, or one of the library upgrades, and see what happens.

If I can't reproduce last tuesday then how do I get back to Friday when shit wasn't on fire?

Re: You don’t need reproducible builds

#103

Post by gumby »

Extreme build reproducibility requirement: had a customer in telecom. Their customers (carriers) required downtime no more than 5 (or 10?) minutes per decade — 7 nines I believe.

When they reported a bug they wanted the fix and then they differed the binary to be sure that every code change was related to the patch itself and nothing else. No additional fixes or upgrades. They were willing to pay through the nose to stay on a very old version of the code.

The code was in C (this was mid 90s) — can’t imagine how much harder it might have been with extensive templating and the like.

Re: You don’t need reproducible builds

#104

Post by johnklos »

This seems like handwaving and arguing against something good because some people don't know how to do things.

"Companies can have security issues. Servers can be compromised. So why try?"

Trying to assert that a demonstrable fact is opinion because the opinionmaker doesn't understand the fact isn't valid.

Re: You don’t need reproducible builds

#105

Post by [deleted] »

joshuamorton wrote: post #100
jeffbee wrote: post #95

Earlier quoted context omitted.

I can't remember seeing any cc_test target at Google that ran with realistic release optimizations (AutoFDO/SamplePGO+LTO) and even if they did it's still not the release binary because it links in the test case and the test main function.

Did you look in the CI system for configurations there? I see FDO enabled in those tests. (Speaking at a high level, configurations can be modified in bazelrc and with flags without being explicitly listed in the cc_test rule itself) > release binary because it links in the test case and the test main function. Sure, but it's verifiably the same object files as get put into the release artifact.

[deleted]

Re: You don’t need reproducible builds

#106

Post by GauntletWizard »

joshuamorton wrote: post #80
Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

Note: This article is not talking about deterministic builds (which are a prerequisite for reproducible builds), but specifically reproducible builds. Reproducible builds are generally speaking interesting only from a security perspective, while deterministic builds have all sorts of useful infrastructural features which the author agrees are useful. And if you think I'm being pedantic, I'm using the official termino…

You're semantically right, but also missing the point. The expense of getting to deterministic builds is large - You have to take great care in your build infrastructure and scripts. The benefits are also large, and worth it.

Once you've gotten to deterministic builds, the expense of getting to reproducible builds is small; Typically days worth of work as opposed to months. The benefits are very different, but far from insignificant, and almost invaluable from a security perspective.

If you're going to do deterministic builds, go for broke - Do reproducible builds.

Re: You don’t need reproducible builds

#107

Post by rmrfrmrf »

If you're looking for an actual spicy take, you could say that reproducible builds are impossible once the durability of hardware/state of the universe is accounted for, but that the concept provides yet another black hole of cash and effort with which devsec can build a cottage industry around.

Re: You don’t need reproducible builds

#108

Post by SkyBelow »

Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

>If a binary is lost, it can be rebuilt exactly as it was. You only need to ensure the source is preserved.

Wouldn't this depend upon the environment as well? Unless the build starts off by creating a build environment, but then we are half way to "To first make bread from scratch, create a universe...".

Re: You don’t need reproducible builds

#109

Post by sreevisakh »

AlexTWithBeard wrote: post #30

Ugh... If building the same source produces different binaries, then I'd like to know (a) what is causing the difference and (b) what other differences does it cause? Being able to produce a consistent result is simply a sign of professionalism.

How about using a different toolchain? (eg: gcc vs clang). Or even different versions of a toolchain? Or a dependency that has to be downloaded? Being able to build consistently requires way more effort than just following professional practices. One method I know is to pin everything that goes into a build - source, dependencies, toolchains, configurations and environment.

Results of non-consistent build can be as simple as a difference in performance. But it could also be a malware injected through the compiler.

Re: You don’t need reproducible builds

#110

Post by trishankdatadog »

Hi Travis,

If you are reading this, I'm one of the members of the TUF [1] and in-toto [2] team, where we try to solve exactly this kind of problems. While I agree with you that reproducible builds sound a lot simpler than they actually are to achieve (and leaving aside all the practical complexities you mentioned in the blog post), I think they provide value for a certain use case seemingly not mentioned in the blog post.

It is the case where the vendor is a traditional Linux distro, and we have independent reproducible builders to ensure that a compromise of their CI/CD infrastructure is not enough to cause malware to be installed. It is true that the builders can still go off and reproducibly build malicious code, but this can be mitigated by requiring a high enough threshold of (presumably independent) developers to sign off the code. The problem of malicious source code is infeasible if not impossible to solve cryptographically, but we can make sure that CI/CD increasingly sitting on the cloud are not blindly trusted.

Could not post on your blog. Let me know what you think. Thanks!

[1] https://theupdateframework.io/ [2] https://in-toto.io/

Post reply on HN