You have to trust the vendor, so if they say "we hired a third party to reproduce our build, and they confirmed our build server produced identical output", then you get the same benefit without having to publish the source and build seeds, right?
-
-
Replying to @taviso @halvarflake and
If you think they might lie, then you can't trust them, and reproducible builds don't have any benefit (because of bugdoors).
3 replies 0 retweets 0 likes -
Replying to @taviso @halvarflake and
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.
2 replies 1 retweet 0 likes -
Replying to @rene_mobile @taviso and
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.
1 reply 0 retweets 0 likes -
Replying to @rene_mobile @taviso and
That is, I don't believe all vendors to be capable of writing completely deniable bugdoors. The low code quality we see in practice means it's a lot easier to write a real, intentional backdoor in a binary-only release (and without repro, you can't match to published source) or
1 reply 0 retweets 0 likes -
Replying to @rene_mobile @taviso and
be compelled to / overridden by another team to add something "bad" at the build stage than to do that undetected (for a time) and deniable (after detection) in source code with reproducible builds. In that spectrum of non-expert-underhanded-coders, I see value in repro builds.
1 reply 0 retweets 0 likes -
Replying to @rene_mobile @halvarflake and
What does it matter if they're good at writing bugdoors or not? There is zero penalty for getting caught, and you get unlimited attempts. That is why the backdoor fixation is so confusing, bugdoors are obviously perfect.
2 replies 0 retweets 1 like -
Replying to @taviso @rene_mobile and
I can prove it's not the case that it's harder to write a bugdoor than a backdoor: People do it accidentally without even trying all the time
Still, I only object to saying it helps prevent backdoors, maybe it improves build quality, but I'm not really sure about that.1 reply 0 retweets 1 like -
Replying to @taviso @halvarflake and
We might have to agree to disagree here. Writing a targeted backdoor for a specific user group and/or shipping a tampered binary to that specific group seems significantly easier to me than writing an innocent-looking bug in the global, published code base. Of course there are
1 reply 0 retweets 0 likes -
Replying to @rene_mobile @taviso and
combinations of other approaches (code signing, transparency logs, paid-for auditors with public reports, etc.) that can mitigate some of these vectors. But if you can do reproducible builds for open source releases with co-signing by independent build servers, why would you not?
1 reply 0 retweets 0 likes
I don't think public reproducible builds are harmful, just not very useful. I guess you should not do that if you have literally anywhere else you can spend resources first, like code auditing, hardening infrastructure, design reviews... etc?
-
-
Replying to @taviso @halvarflake and
Luckily, a lot of that work has already been done (https://reproducible-builds.org/tools/ , diffoscope e.g. is great and fairly easy to run), and from my point of view reproducible builds are very quickly getting to where unit tests, static checkers, and fuzzing are now: standard tools to apply.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.