I don't really know what reproducible builds prove, that the build server wasn't compromised? If Signal were malicious, they could just add a bugdoor, so you still have to trust them not to be malicious. 
-
-
Reproducible builds make most sense together with open source, of course. And it's of value even if nobody is constantly verifying the builds. Simply the point that they could mitigates the vector of a malicious builds server. Source level backdoors are certainly not addressed.
1 reply 0 retweets 8 likes -
Replying to @rene_mobile @fugueish and
You can prove the build server isn't compromised, but you can't prove you're not trying to hide a backdoor, right? So users still have to trust you, and you could get the same benefit from getting a third party to privately repro the build for you...
3 replies 0 retweets 6 likes -
I don't fully agree. It is still easier to hide a backdoor in (obfuscated) binary code than it is in (written-to-be-maintainable) source code. Config should ideally be included. And there are other code quality benefits of reproducible builds besides security (testing, deltas).
2 replies 1 retweet 11 likes -
Replying to @rene_mobile @fugueish and
Is it easier? The benefit of bugdoors isn't ease, it's that they're plausibly deniable, if you get caught, so what? You might even be able to convince people not to talk about it for months, and you can try again in a new patch, there's zero penalty.
2 replies 4 retweets 23 likes -
Replying to @taviso @rene_mobile and
There might be non-security benefits of reproducible builds to *vendors*, but I don't see any benefit to users of being able to reproduce them. This is just because promising there's no backdoors make no sense when bugdoors are just so perfect?
1 reply 0 retweets 6 likes -
Replying to @taviso @rene_mobile and
Fwiw I see benefits in reproducible builds to answer the question "is the binary on my machine built from this source"?
3 replies 0 retweets 33 likes -
Replying to @halvarflake @rene_mobile and
Yes, but that only makes sense if you trust the person who provided the source code (because if you don't trust them, there could be a bugdoor). So another way to verify that would be codesigning, or hosting the binary on a https server, right?
4 replies 0 retweets 3 likes -
Replying to @taviso @halvarflake and
Code signing doesn't solve the issue of knowing "what code was signed" at the moment of signature. The signature can of course cover a claimed checksum of the code, but even then, it's hard to verify. That does not make signatures bad, it only doesn't solve the same issue.
1 reply 0 retweets 1 like -
Replying to @spidler @halvarflake and
Yes, but the point is you *have* to trust the vendor. It makes no sense to say you trust their code but not their signature, right?
2 replies 0 retweets 1 like
Let's say the vendor is malicious, so they hide a bugdoor in the code and sign it. You don't trust code signatures for some reason though, and demand a reproducible build.... so what? You now have a reproducible bugdoor. If you do catch them, "oops", and there's zero penalty. 
-
-
You can make an update system where independent entities reproduce a build and sign and then you check m of N signatures of m trusted by you instead of trusting SSL/TLS CAs.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I hadn't thought of this in the context of the software supply chain. A "trusted" vendor could include a library or tool in their build process that can add a bugdoor. Even if you have the vendor's source code, it would be an uphill fight to find, and determine intent.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.