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).
If you think they might lie, then you can't trust them, and reproducible builds don't have any benefit (because of bugdoors).
-
-
Reproducable builds are a supply-chain control, not a quality control. They don't fix the garbage in, garbage out problem. But verifying that the garbage I'm receiving is in fact exactly the garbage the vendor produced still has value.
-
If you read the tweet above, I explained why that isn't the case. If you have a counterargument, you have to make it

- 11 more replies
New conversation -
-
-
So your argument is "reproducible builds are useless because I have to trust the vendor not to bugdoor things"?
-
(my view is: As vendor, I like reproducible builds & providing source as it (a) increases the chance that a compromised build infra will be noticed if leveraged and (b) helps me tie source code revisions to binary builds more easily)
- 14 more replies
New conversation -
-
-
I think I now know the difference in our mental threat model. Do you assume vendors to be fully capable of securing their build infrastructure if they also write trustworthy code? I.e. either the lie about their code (and are capable of writing good bugdoors), or they are honest.
-
I see it as a non-binary spectrum. Most vendors make mistakes. One set of engineers writes code, a slightly different set might build it and send you binaries. Then another vendor packages it in a bigger piece, again building/linking on their infra. Lots of mistakes happen.
- 8 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.