In GPG release verification, how do you establish that the signing key really belongs to the project?

## The question cryptography does not answer A detached signature proves the artifact was signed by the holder of a particular key. Whether that key is *the project's* is a separate problem — key discovery and trust — and every real-world failure of GPG release signing lives here rather than in the mathematics. ## The channels, and what each one actually buys **A KEYS file on the project's own site.** The most common arrangement and the weakest. If an attacker owns the web origin, they serve a tarball and a matching signature from a key they generated, and every consumer who bootstraps from that page verifies successfully. What you still gain is real but narrow: protection against *mirrors* and transport, because the mirrors do not hold the key material the origin published, and a durable record you can re-check later. What you do not gain is any independence from the origin itself. **A public key directory keyed on email (Web Key Directory).** The key is fetched over HTTPS from a well-known path on the domain in the key's user ID. This is convenient and automatable, but the trust anchor is that domain's DNS and TLS — for a project whose website and key domain are the same, it is the same circle as above, drawn slightly larger. **Keyservers.** Historically a flooding-prone gossip network: anyone could attach unlimited third-party certifications to anyone's key, and keys were deliberately spammed until clients choked trying to import them. The widely used modern replacement verifies control of the email address and then distributes only the key's self-signatures and identity, **stripping third-party certifications**. That makes it abuse-resistant and usable, at the cost of no longer carrying the certifications the web of trust depended on. A keyserver is therefore a *distribution* mechanism, not a trust mechanism: it tells you a key exists, never that it is the right one. **Your OS distribution's keyring.** For most engineers this is the channel that genuinely works, because the trust was bootstrapped once, out of band, when the install media was obtained and verified, and the keyring is maintained by people whose job is to track upstream key changes. You have delegated the problem to an intermediary — which is a legitimate answer, provided you can say who the intermediary is. **Out-of-band fingerprint plus pinning.** Obtain the full fingerprint from somewhere the download origin does not control — a printed proceeding, an announcement signed by a key you already hold, a second organisation that republishes it, a person you met — and then pin it. Pinning is the operational half: a verification step that accepts *any* key in the keyring is not a gate, so the accepted fingerprint has to be an explicit input. **Continuity.** A new release key certified by the outgoing one is strong evidence *if* you already had the outgoing one. It chains trust forward but cannot create it, which is why the first key a consumer ever imports is the expensive one. ## The web of trust and why it did not carry this The design was that people certify each other's keys, verifiers assign ownertrust to a few introducers, and GnuPG computes whether enough marginally- or fully-trusted paths reach an unknown key. It works inside dense communities that hold key-signing events. It never worked for the general case of "I want to install this library": no path exists from a random engineer to a maintainer three continents away, nobody configures ownertrust, and the certifications themselves stopped being distributed by the very service most people now fetch keys from. In practice almost every verifier runs with an empty trust model and reads the `[unknown]` warning as noise. ## The scenario that makes it concrete A procurement team onboarding a vendor asks for PGP-signed builds — a sensible-sounding contractual control. The vendor delivers, and the key arrives with no third-party certifications on it, discoverable only from the same website that serves the installer. The buyer's verification step now proves: *whoever controls that website also produced this signature*. If the vendor is compromised, or if that site is, the signature validates exactly as before. The buyer has bought tamper-evidence in transit and an audit artifact, and has bought nothing at all against a compromised supplier. The fix is unglamorous: get the fingerprint through a second channel — the contract itself, a named security contact confirming it on a call, a copy held by an intermediary — pin it, and require notice before any key change. ## The takeaway to say in an interview "Signature verification is only as strong as key discovery, and key discovery is a trust decision you have to make deliberately: name the channel, pin the fingerprint, and know which intermediary you are relying on."