If an attacker wanted to hand me bad code, couldn’t they also hand me a bad signature/certificate/key?

This is what multi-party key signing is for. Now, multiple people verify code, and also verify build artifacts. Rather than trusting an individual, you trust a process during which developer’s continuously verify each other.

The other thing to note is that the builder is not always the distributor. For example many Linux distro’s have mirrors setup, where they share their built artifacts to other institutions and hosters, who then redistribute code.

Even for a single party, key signing has value because it ensures that everything after the original creation of the artifacts is not compromised, as long as the key distribution system is different than the distribution system of the artifacts.

But for a solo dev on Github, yes. Signing doesn’t really do anything, since the developer and the distribution chain are close enough that it’s highly likely the key would be compromised along with the source.

well for the signature, if you have the key, and the author signs future releases with the same key then if an attacker ever compromises the download page but not the signature then the signature won’t match the key you already have. This is also part of what makes repositories better than a plain .deb because the key and so on is fetched and then checked by the update tool automatically ever after. The point isn’t to protect people of interest. It is assumed that a dedicated attacker will find a way. It is to prevent wide net attacks that discriminate less and decide what to do with who gets compromised after the compromise.

The hash is mainly so you can verify file integrity, i.e. that the file on your disk is the same one that the website offered. It doesn’t provide any claims about authorship or security. So you don’t end up writing half an ISO to your thumbdrive and wondering why it won’t boot or something.

The key concepts here are “validity” versus “trust.” You can use gnupg to mark a key as “trusted,” and when you validate a signature, PGP checks to see if if the signing key is trusted. So hypothetically you’d download the key, mark it as trusted on your machine, and then next time you download the software, you can verify the signature, and PGP says the signature is valid and trusted. Here’s a post from the Linux foundation about trust: PGP Web of Trust: Core Concepts Behind Trusted Communication.

You’re right that if you download something at the same time you download the signature, it’s possible that both were tampered with. This is where key signatures come into play. In PGP, key signing is very important because it forms a web of trust, where keys are signed by other keys, which is like a public declaration that the signing key trusts the signed key. Then, when you verify a signature, PGP tries to find a chain of signatures, starting from a key you’ve directly marked as trusted, to the key that made the signature you’re verifying. Here’s part 2 of the Linux Foundation’s series on PGP trust that follows that first post: PGP Web of Trust: Delegated Trust and Keyservers.

This is entirely separate from just verifying a hash. If you get like an MD5 or SHA256 hash of a file, that is purely for checking that the file didn’t get corrupted by a bad download, etc.