Reproducible builds make most sense together with open source, of course. And it's of value even if nobody is constantly verifying the builds. Simply the point that they could mitigates the vector of a malicious builds server. Source level backdoors are certainly not addressed.
The discussion is around publishing reproducible builds for the public though, right? This is a way of verifying your build process isn't compromised, but you don't need to publish them and hope the public checks it for that.
-
-
It’s a way for auditors and customers to verify as well. And the general public, if you consider them to be auditors.
-
Right, so let's say I trust the vendor, but I think their build might be compromised. You're saying "now you can verify their build isn't compromised, but you still have to trust there are no bugdoors", so why wouldn't you trust them not to promise they checked the build repro'd?
- 6 more replies
New conversation -
-
-
You can simply hire a third party to do it for you, and then promise you checked for a compromised build. Your users have to trust you anyway, because they need to trust you're not inserting bugdoors.
-
Reproducible builds offer a relatively cost effective way to replace your third party (who now has to verify ever point release and security patch), without adding new trusted parties. That alone seems like a win.
- 1 more reply
New conversation -
-
-
This is a bit of a tangent, so feel free to ignore, but if the code is open and formally verified (a la Coq), then a bugdoor is reduced to the formal proof itself. This might be useful in some small, specific use cases, and I'm not claiming to have seen in the real world :-)
-
Although maybe for
@benadida@voting_works voting type applications? - 3 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.