I think rather than malicious developers the focus is on malicious build machines. How many things are built solely via CI these days, on machines that nobody has ever seen, using docker images that nobody has validated?
It's much easier to imagine a malicious provider (as in Sourceforge bundling in adware) than malicious developers, I think.
But yes, you're right that reproducible builds don't remove the need to trust the source.
>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.
This is pretty much all false though - not only the "just" part, as setting up a proper build environment is pretty non-trivial for many projects, and building everything from source is a task only the most dedicated Gentoomen would take up; you can also think of reproducible builds as a "litmus test". If you can, with reasonable accuracy, check whether a build machine is compromised at any time, you have a much greater base on which to trust it and its outputs. The benefits of having build machines probably shouldn't need explaining.
>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.
>...
>The problem is now you've either just replaced build servers with killswitches, or just replicated the same potentially-compromised buildserver.
I really don't understand this argument; compromised infrastructure probably shouldn't be a regular occurrence, and even if so, automated killswitches seem like the vastly more preferable option, no?