I think people generally agree now that reproducible builds don't prevent backdoors. That's good, but now they want to argue for other fuzzier benefits, so it's harder to follow that!
-
-
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 reply 0 retweets 0 likes -
Replying to @rene_mobile @taviso and
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 reply 0 retweets 0 likes -
Replying to @rene_mobile @taviso and
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 reply 1 retweet 2 likes -
Replying to @DanielMicay @rene_mobile and
Let's not drift from the core discussion, maybe homeopathic remedies have the benefit of the placebo effect, but they don't cure disease. Do reproducible builds mean you don't need to trust the vendor, or eliminate backdoors? The answer is no, agreed?
2 replies 0 retweets 1 like -
Replying to @taviso @rene_mobile and
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 reply 0 retweets 0 likes -
Replying to @DanielMicay @taviso and
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 reply 0 retweets 0 likes -
Replying to @DanielMicay @taviso and
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 replies 0 retweets 1 like -
Replying to @DanielMicay @taviso and
It's not absolute size but delta. If your distro or someone who ported the FOSS to Windows is shipping a binary, relevant size is their diff vs upstream. Repro builds lets you audit what they did.
1 reply 0 retweets 1 like -
Replying to @RichFelker @DanielMicay and
Dismissal of value of repro builds ignores the reality of FOSS supply chain where multiple intermediary parties are involved in getting you a binary and you have different trust relationship with each.
2 replies 0 retweets 3 likes
Then spell it out for me Rich. You have the source code, and a binary that someone you trust says is produced from that code, correct? You have to make your own binary, so why not just use that one? Why are you so determined to use the other byte-for-byte identical one?
-
-
Replying to @taviso @DanielMicay and
Because I'm getting the binary from App Store or Play Store or some other channel and can't or don't want to enable manual sideloading.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @DanielMicay and
Let's explore this threat model you're trying to solve: You're using the Play Store and you trust all the platform binaries, you also trust the vendor, but you think their build is compromised. You can't sideload, so how do you get the App Store binaries to check?
1 reply 0 retweets 0 likes - 2 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.