Conversation

Oh, I never thought they _prevented_ backdoors, only that some of the easier vectors for introducing them are being mitigated. And that seems a good thing, especially in combination with my strong suspicion (only anecdata, though) that it helps code (or at least build) quality.
1
And since I can't see any real harm with reproducible builds (besides the work it takes to set up in the first place) - i.e. no runtime overhead etc - I don't see the usual discussion of cost of mitigation measures to factor in much in this debate. So, why not build reproducibly?
1
The auditing / trust benefits are largely theoretical, esp. outside tiny projects... but reproducible builds are very useful nonetheless. Regularly helps me debug problems, analyze the impact of changes and even figure how to build things properly. Bonus: smaller delta updates.
1
2
The theoretical benefits of reproducible builds are based on the theoretical benefits of open source. I don't think reality matches anything close to the hype. I don't think either does much to avoid trust in vendors/developers. I think both help making software better though.
1
It depends a lot on the project. It gets much less useful as the code size / complexity of the project increases. It's more useful if the project uses a simple type/memory safe language where there are far fewer subtle ways of horrible things happening so it's easier to check.
1
If we're talking RCE backdoors and a typical 250k LOC C++ project, reproducible builds do not accomplish anything in terms of reducing trust in the vendor / developer. If it's some 25k LOC Go project not doing anything insane, decent assurance of no RCE backdoors seems tractable.
2
1
I interpreted the question as being about trust in the software vendor / developers. Reproducible builds are a lot more clearly useful for downstream builds / distribution especially if they don't change anything substantial. It's just not how I interpreted the discussion.
1