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).
I don't see how a supply chain attack is relevant. I think reproducible builds prove your build server isn't compromised and nothing else, it doesn't reduce the need to trust the vendor. As you already trust the vendor, what's wrong with codesigning or similar?
-
-
Is there value in being able to state "this binary is derived from that source code"? I think yes, independently of whether I am the vendor or user. But I won't argue that repro builds solve backdoors.
-
Fwiw it's a bit sad that repro builds even need discussing; imo deterministic repro builds should be about as exotic as a working "ls".
- 14 more replies
New conversation -
-
-
Hmm no, reproducible builds don't prove your server isn't compromised, it makes it a bit harder for an attacker to hide malicious code (not impossible)
-
I think they can prove the build server wasn't compromised, but for the sake of discussion, let's say it doesn't. What is the attack you're imagining, is the vendor malicious in your scenario? If not, how did the attacker get the build codesigned?
- 2 more replies
New conversation -
-
-
Yeah I totally agree, but it helps other vendors/customers trust you.. Your build server is the fruit of your supply chain's labour, as such, code signing is all you've got to let the customers of the vendors of you trust you and the people who sold you aforementioned server?
-
(Hence hacking my build infra)
End of conversation
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.
