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).
-
-
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 @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 @taviso and
Even more true if the software in question is FOSS with minor vendor patching. Knowing the source they showed you corresponds to what they shipped lets you limit audit to their patches.
1 reply 0 retweets 4 likes -
Replying to @RichFelker @matthew_d_green and
Vendors lying about extent to which they modified FOSS in their products is a huge issue repro builds fully fixes, and is absolutely relevant to approach to evaluating safety.
1 reply 0 retweets 5 likes
If you don't trust the vendor to tell the truth, how can you trust them not to insert a bugdoor?
-
-
Replying to @taviso @matthew_d_green and
Threre's a big difference in trust to be nonmalicious and trust to be competent and not hiding embarrassing things.
1 reply 0 retweets 6 likes -
Replying to @RichFelker @taviso and
But if you have proof the patches are correct & scope is auditable you *don't have to trust*.
1 reply 0 retweets 2 likes - 20 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.