Fwiw I see benefits in reproducible builds to answer the question "is the binary on my machine built from this source"?
-
-
Replying to @halvarflake @taviso and
Without reproducible builds, source analysis offers zero benefit. With reproducible builds, it offers some benefit. For example, crypto bugdoors that allow mass-scale passive decryption are possible (Dual EC, Fortinet) but are also extremely rare.
2 replies 1 retweet 27 likes -
Replying to @matthew_d_green @halvarflake and
What benefit does it offer? There's no penalty for making a bugdoor, so if you catch the vendor's bugdoor, they have to make a new one?
2 replies 0 retweets 4 likes -
Replying to @taviso @matthew_d_green and
To be clear, source analysis is useful to catch non-malicious vendors who make a mistake. If you're trying to determine if a vendor *is* malicious, src analysis provides no benefit, because there is no penalty for hiding a bugdoor....so how do repro builds help?
1 reply 0 retweets 6 likes -
Replying to @taviso @halvarflake and
There are a lot of people involved in the build process. And a much smaller number of people involved in the development of specific portions of code. If you can isolate your security concerns to those areas (still aspirational) you can reduce your trusted dev base.
2 replies 0 retweets 11 likes -
Replying to @matthew_d_green @halvarflake and
The discussion is around publishing reproducible builds for the public though, right? This is a way of verifying your build process isn't compromised, but you don't need to publish them and hope the public checks it for that.
3 replies 0 retweets 0 likes -
Replying to @taviso @halvarflake and
It’s a way for auditors and customers to verify as well. And the general public, if you consider them to be auditors.
1 reply 0 retweets 3 likes -
Replying to @matthew_d_green @halvarflake and
Right, so let's say I trust the vendor, but I think their build might be compromised. You're saying "now you can verify their build isn't compromised, but you still have to trust there are no bugdoors", so why wouldn't you trust them not to promise they checked the build repro'd?
3 replies 0 retweets 0 likes -
Replying to @taviso @halvarflake and
In order for them to check the build, they’d have to engineer reproducible builds anyway. So the costs have already been incurred. Might as well make them available to your auditors at no additional cost, so they can eliminate another trust point.
2 replies 0 retweets 3 likes -
Replying to @matthew_d_green @taviso and
I also think you’re considering a model where there’s a binary choice between absolute trust and no consequences for serious bugs, and zero trust. There’s a spectrum.
1 reply 0 retweets 3 likes
It would be nice if that was true, but every month the major vendors publish dozens of backdoor-equivalent vulns. Doesn't that prove there are no penalties for bugdoors? Worse, there might be social penalties or threats to you for discussing a bugdoor you discovered 
-
-
Replying to @taviso @halvarflake and
If you imagine deliberate bugdoors created by nation states, you also have to consider that good bugs can be discovered and exploited in both directions.
1 reply 0 retweets 1 like -
Replying to @matthew_d_green @halvarflake and
Not really, you already mentioned Dual-EC. As I understand it, they argue they generated them randomly and it was a genuine spec-bug. You argue is was a bugdoor, but it can only be exploited in one direction, right? The same is true for other bug classes.
1 reply 0 retweets 0 likes - 29 more replies
New conversation -
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.