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 @matthew_d_green and
It makes no sense, right? You either trust the code *and* trust them that they verified the build wasn't compromised, or you don't trust them... and it's meaningless? I really think published reproducible builds are a red herring.
1 reply 0 retweets 1 like -
Replying to @taviso @matthew_d_green and
I think reproducible builds are useful for locking down a few classes of attack -- delivering dif builds to dif folk, and knowing that the source you see results in the build you're running. There are other attacks, like bugdoors. But don't let perfect be the enemy of better.
1 reply 0 retweets 2 likes
Right, but when you use the "don't let perfect be the enemy of the good" argument, you have to show you're making things better. Bugdoors are easier, equivalent, plausibly deniable and zero penalty if you're caught. How have you made things better?
-
-
Replying to @taviso @jeffmcjunkin and
If we spend millions working on solving an attack that nobody would ever use, I'm not sure we have made things better?
1 reply 0 retweets 1 like -
Replying to @taviso @matthew_d_green and
I'm not sure we have good data on bugdoors vs single-target altered builds, honestly. Bugdoors are significantly harder to detect, of course. I'm still astounded at the Obfuscated C Code Contest winners. That said, altered builds are still a plausible concern, so still a win.
1 reply 0 retweets 0 likes - 1 more reply
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.