Forgive me if someone has already mentioned this, but if I have multiple vendors, why can't I compare the hashes of all of them before I ask for the binary? Then any one vendor is being held to account by the others before I install. No source is required, just the hashes of the source and the hashes of the resultant binary.
You don’t need reproducible builds
151–160 of 179 posts
Re: You don’t need reproducible builds
#152A number of large companies are quietly moving towards reproducible build. Sorry if I cannot name the names. As a side note, reproducible builds implemented in Debian were also useful to spot various other problem: small differences in build environment that would make debugging more difficult. Sometimes the same application will have different performance depending on the build due to memory alignment, data ordering…
> A number of large companies are quietly moving towards reproducible build. Sorry if I cannot name the names. Thanks, user "ex_amazon_sde"!
I wrote "a number" and I was not referring to Amazon :)
Re: You don’t need reproducible builds
#153Earlier quoted context omitted.
And vendor malice isn't the only reason why the software might be harmful. What if the vendor's toolchain was compromised without their knowledge? Reproducible builds provide a means for third parties to verify that it wasn't.
The holy grail of reproducible builds is achieving the same binary via different compilers. This was, at least when I started looking into reproducible builds, why I wanted to do it and why others wanted to do it. The other benefits are kind of side benefits.
> the same binary via different compilers
Are you sure you aren't thinking of diverse double-compiling[0]? Which specifically does not require different compilers to produce the same output[1], just different runs of different binaries of the same compiler.
0: https://dwheeler.com/trusting-trust/dissertation/html/wheele...
Re: You don’t need reproducible builds
#154Earlier quoted context omitted.
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 fr…
It really depends. If I’m building a Java project, I’m pretty sure I’ve got a deterministic build just by running javac pointed at a source directory. If I want a reproducible build, I probably need to do a lot more:
- ensure timestamps of all files embedded in jar files is consistent
- ensure there is no BuildTime/BuildHost/BuildNumber variable of any kind being captured
- ensure the exact version of compiler is documented
- ensure exact versions of all dependencies in classpath is captured
Re: You don’t need reproducible builds
#155> Q. If a user has chosen to trust a platform where all binaries must be codesigned by the vendor, but doesn’t trust the vendor, then reproducible builds allow them to verify the vendor isn’t malicious. > I think this is a fantasy threat model. If the user does discover the vendor was malicious, what are they supposed to do? > The malicious vendor can simply refuse to provide them with signed security updates instead…
Yes, the argument in the article seems to revolve around it is harder user to verify a build that it is to simply build it themselves. If they build it themselves there is no need to verify it of course - so what's the point of verification?
You could apply that same argument to lots of things. It's hard to verify things adhere to standards in general - whether it be flammability of children's clothes, or additives in food. Bu that logic I should be making my own clothes and meals rather than relying on the manufacturers claims.
Obviously, no one does. The point is someone has made a verifiable statement, in public. There is no need to go to the effort of testig that statement a zillion times. In fact needn't be done at all in many cases - just the treat of doing the test with something goes wrong suffices. In the case of food where I live, a recent recall of strawberry's devastated the industry. No one was testing if strawberry's contained needles until someone eat one, no one got seriously hurt when they did. Well no body except the strawberry industry which was on its knees for months until once again people started to take them at their word their product was safe to eat.
Similarly if you care about security (and I do), if there was a choice between several several Signal like programs that all claimed verifiable builds, and then it was shown one was in fact lying about verifiability I'd drop them like a hot potato. And I wouldn't be dropping them for just months like the strawberry's, it would likely be forever.
In one line: the idea that every user has to test a verifiable build does in fact verify in order for it to be useful, is seriously flawed.
Re: You don’t need reproducible builds
#156Has someone taken over Tavis's blog? Two posts in a row now that seem like he either just doesn't understand some concepts, or is intentionally disseminating nonsense that is pushing people in the wrong direction on things that really do bring about benefits related to security.
Re: You don’t need reproducible builds
#157Earlier quoted context omitted.
What is the difference?
Deterministic build means every time you compile the same source you get the same executable. Reproducible build means that you specify and relay enough information to allow everyone else to reproduce your results for themselves in their own environment.
Haha thanks.
So one has hidden variables that happen to be locally constant, and the other is purged of hidden variables.
Re: You don’t need reproducible builds
#158It looks like almost everyone here thinks this is wrong and poorly argued (as do I). A meta question to ponder: why did this get upvoted to the front page? Is it that upvoters tend to not read the articles whereas commenters do? Do people upvote stuff they think is wrong for the purpose of discussion?
As much as we like to pretend to only look at the arguments itself, I think part of the reason is because Travis is a pretty well known hacker. If I or you had published it, it probably would not have made it to the front page.
Even if I disagree with his overall opinion on reproducible builds, I think he does bring forward valid arguments and I personally took something away from reading his blog post (e.g. the word bugdoor).
But to your point, I think up-voting is a sign of approval, while commenting usually is used to criticize. Why would anyone comment on something they 100% agree with?
Re: You don’t need reproducible builds
#159Earlier quoted context omitted.
> You could check it on your computer of course App Store-distributed ipas can’t be decrypted without keys burned into iOS hardware, so you can’t decrypt them on a Mac without a jailbroken iOS device. (You can hash the encrypted binary but of course that’s pretty useless for reproducibility.) This might be about to change since Apple has announced support for running iOS apps directly on Apple Silicon Macs?
The Apple Silicon Macs probably have the exact same hardware, but you don’t have to really “jailbreak” then I guess…
Yeah that’s what I meant.
Re: You don’t need reproducible builds
#160Hi 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…
I think it's "Tavis" (no "r")