5 ms·

I don't see a single comment doubting the value of reproducibility, so I'll be the resident skeptic :) I think build reproducibility is a cargo cult. The websi

by taviso 5y ago

I don't see a single comment doubting the value of reproducibility, so I'll be the resident skeptic :) I think build reproducibility is a cargo cult. The website says reproducibility can reduce the risk of developers being threatened or bribed to backdoor their software, but that is just ridiculous. Developers have a perfect method for making their own software malicious: bugdoors. A bugdoor (bug + backdoor) is a deliberately introduced "vulnerability" that the vendor can "exploit" when they want backdoor access. If the bug is ever discovered you simply issue a patch and say it was a mistake, it's perfectly deniable. It's not unusual for major vendors to patch critical vulnerabilities every month, there is zero penalty for doing this. The existence of bugdoors means you have to trust the vendor who provided the source code, there is no way around this. You have to trust the developer, but in theory, reproducible builds could be used to convince yourself their build server hasn't been hacked. This isn't really necessary or useful, you can already produce a trustworthy binary by just building the source code yourself. You still have to trust the vendor to keep hackers off everything else though! Okay, but building software is tedious, and for some reason you are particularly concerned about build servers being hacked. Perhaps you will nominate a dozen different organization that will all build the code, and make this a consensus system. If they all agree, then you can be sure enough the binaries were built with a trustworthy toolchain. A modest improvement in theory, but that introduces a whole bunch of new crazy problems. You can't just pick one or two consensus servers, because then an attacker can stop you getting updates by compromising any one of them. You will have to do something like choose a lot of servers, and only require 51% to agree. Now, imagine a contentious update like a adopting a cryptocurrency fork, or switching to systemd (haha). If the server operators rebel, they can effectively veto a change the vendor wants to make. Perhaps vendors will implement a killswitch that allows them to have the final say, or perhaps they operate all the consensus build servers themselves. The problem is now you've either just replaced build servers with killswitches, or just replicated the same potentially-compromised buildserver. I wrote a blog post about this a while ago, although I should update it at some point. https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducible-builds.html https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducibl...

dane-pgp 5y ago
> If the server operators rebel, they can effectively veto a change the vendor wants to make. How often do you think there will be a change so controversial that teams who have volunteered to secure the update system will start effectively carrying out a Denial of Service attack against all the users of that distro? We also have to imagine that these malicious attestation nodes can easily be ignored by users just updating a config file, so the only thing the node operators could achieve by boycotting the attestation process is temporarily inconveniencing people who used to rely on them (which is not a great return on investment for the reputation they burn in doing this).
- taviso 5y ago
  I don't know what reputation damage will happen, they're just third parties compiling code. There is no reputational damage for operating a malicious tor exit relay, why would this be different?
  - dane-pgp 5y ago
    As I understand it, Tor does have a way of detecting whether an exit node is failing to connect users to their intended destination. (With TLS enforced, the only thing a malicious exit node could do is prevent valid connections). In any case, I don't think anyone is proposing that the attestation nodes be run by random anonymous people on the internet. It would make more sense to have half a dozen or so teams running these nodes, with each team being known and trusted by the distro in question. I'm not sure what the costs/requirements would be for running one of these nodes, but it might be possible for distros to each run a node dedicated to building each other's distros (or at least the packages that are pushed as security updates to stable releases). Alternatively, individual developers that already work on a distro can offer to build packages on their own machines and contribute signed hashes to a log maintained by the distro itself.
    - taviso 5y ago
      The point was that a reproducible build doesn't mean you don't have to trust the developer. Build servers rebelling was just an example of the additional complexities and attacks that it introduces, for very negligible benefit.

by taviso 5y ago

dane-pgp 5y ago

> If the server operators rebel, they can effectively veto a change the vendor wants to make. How often do you think there will be a change so controversial that teams who have volunteered to secure the update system will start effectively carrying out a Denial of Service attack against all the users of that distro? We also have to imagine that these malicious attestation nodes can easily be ignored by users just updating a config file, so the only thing the node operators could achieve by boycotting the attestation process is temporarily inconveniencing people who used to rely on them (which is not a great return on investment for the reputation they burn in doing this).

taviso 5y ago
I don't know what reputation damage will happen, they're just third parties compiling code. There is no reputational damage for operating a malicious tor exit relay, why would this be different?
- dane-pgp 5y ago
  As I understand it, Tor does have a way of detecting whether an exit node is failing to connect users to their intended destination. (With TLS enforced, the only thing a malicious exit node could do is prevent valid connections). In any case, I don't think anyone is proposing that the attestation nodes be run by random anonymous people on the internet. It would make more sense to have half a dozen or so teams running these nodes, with each team being known and trusted by the distro in question. I'm not sure what the costs/requirements would be for running one of these nodes, but it might be possible for distros to each run a node dedicated to building each other's distros (or at least the packages that are pushed as security updates to stable releases). Alternatively, individual developers that already work on a distro can offer to build packages on their own machines and contribute signed hashes to a log maintained by the distro itself.
  - taviso 5y ago
    The point was that a reproducible build doesn't mean you don't have to trust the developer. Build servers rebelling was just an example of the additional complexities and attacks that it introduces, for very negligible benefit.