If the binaries get tampered with on the server, then the file will fail the verification. If the signature gets tampered with on the server, the file will also fail the verification. I don't see how any tampering can cause problems, provided the OpenBSD project team publishes their public key widely [0].
[0] There is an attack where the adversary distributes malicious binaries signed with a key that appears to belong to the OpenBSD project, but which in reality would belong to the adversary. This could work if the adversary manages to mislead the user, but if the OpenBSD project team uploaded their public key all over the Internet (and preferably announce it on the mailing lists and home page), then this attack is ineffective. During signature verification, the key ID that created the signature is displayed and the user would know that something is wrong if the signature has not created by the usual OpenBSD signing key.
>If the signature gets tampered with on the server
Sorry, I meant the key. As all the linux distros using PGP signing demonstrate, people don't bother to verify the key, they just accept it blindly and assume everything is cool. Since only 1 out of a million people ask for this, and of those only 1 out of a million would actually go through the correct procedure rather than just grabbing the key from the same place they are grabbing the binaries and not verifying it in any way, it isn't worth the effort. The 0.001% of the 0.001% already have the tools available to verify, it is just a bit of a pain to do. It isn't worth it for the openbsd devs to waste time making it easier for those people who wouldn't verify the key anyways to feel secure when they would be exactly as secure as they are now. That's what I mean by security theatre.
What you mean by security theater is that because some users don't verify binaries, it doesn't matter if anyone is able to verify binaries. You're trolling. Please go away.
Please, keep spamming "ur a troll!!1" like a child, it is very productive and adds a great deal to the discussions at HN. As I said, the 0.001% of the 0.001% who actually want to verify can already do so. Several mirrors have widely known ssh pubkeys.
He doesn't need the PGP key, he tampered with the software before it was signed. I just phrased it that way in response to your absurd statement, a fact that should be painfully obvious. Theo is the guy in charge. He is the guy building the software. He would be the guy signing the software. When Bob owns the build server, he can trick Theo into signing his malicious binaries. Do you think Theo goes through each binary with a disassembler after he compiles them and ensures that the generated binaries are kosher? All PGP would get me is the ability to know Theo signed it. If it was tampered with during the build, or post-build, pre-signing, then I'm boned.
That is the same situation we currently have. If Theo's machines get owned, we're boned. If they don't, we can easily verify that the sha-256 hash of the files on my hard drive, post download from wherever, match those that Theo built.
At the end of the day, you are drawing a line about where to stop verifying and start trusting. The fact that you are download binaries as opposed to source means you are trusting the openbsd developers, not just personally, but in that they have secured access to the code and build process to prevent tampering. So then the only part you aren't trusting is the distribution mechanism, which ssh keys and sha-256 hashes allow you to verify, rather than needing to rely on trust.
"If Theo's machines get owned, we're boned" is not the scenario that signed releases addresses.
No doubt you can concoct a scenario involving malicious robotic brain worms coercing Matthew Dempsky into committing a malicious system call. "PGP doesn't address that!", you'll say, "so it's all just theater".
At the end of the day, you're simply wrong about the utility of release signing. You were mistaken about whether their security was compromised because signatures are fetched from the same location as the binaries (you were tripped up by the concept of "public key cryptography" there). And you were mistaken about the different threat models handled by SSH vs. PGP keys.
I know you aren't actually this stupid, so what exactly is the purpose of your continued trolling? We both know PGP is only covering the distribution portion of the chain. If Theo is owned we're fucked, and if we're owned were fucked (obviously). This is true with PGP, or with what we have now.
So you are saying the openbsd devs should waste time with PGP to solve an issue that is already solved (distribution security). The machine that would be signing the releases is already generating sha256 hashes of them. So as long as you can verify you are getting those hashes from that machine, you are as secure as you can get, PGP or not. And since you can get them over ssh, with a well known public key, you already have everything you need to deal with tampering during distribution. If the machine was compromised and those hashes altered, then it would have been just as much an issue if PGP were in use, since they could alter the binaries before they were signed. You already know all of this, I know you know this, you know you know this, so what are you trying to accomplish by pretending you caught a sudden case of mental retardation?
[0] There is an attack where the adversary distributes malicious binaries signed with a key that appears to belong to the OpenBSD project, but which in reality would belong to the adversary. This could work if the adversary manages to mislead the user, but if the OpenBSD project team uploaded their public key all over the Internet (and preferably announce it on the mailing lists and home page), then this attack is ineffective. During signature verification, the key ID that created the signature is displayed and the user would know that something is wrong if the signature has not created by the usual OpenBSD signing key.