A project's PGP release key was revoked years ago. Why do verifiers still accept its signatures?

## How OpenPGP revocation works A key is revoked by generating a **revocation self-signature** — a signature made with the key's own private half (or a revocation certificate produced in advance and stored separately, for the case where the key is lost) — and then attaching it to the public key and publishing it. Any verifier who obtains a copy of the key *carrying that revocation* will report the key as revoked. Everything hard is in the phrase "who obtains a copy carrying that revocation". ## Why the revocation never arrives **Verification is offline by design.** `gpg --verify` recomputes a digest and checks a signature against the key already in the local keyring. There is no network step, no status responder, no revocation list consulted, nothing analogous to the online status checks in the TLS certificate world. Offline verification is a *feature* of this model — it is why air-gapped and long-horizon consumers like it — and revocation propagation is precisely the price. **Local copies go stale silently.** A key imported five years ago is frozen at the moment of import. Refreshing is an explicit, manual act (`gpg --refresh-keys`), it is not scheduled anywhere by default, and on many keys it fails or is slow enough that people stop doing it. **Automation never even looks.** The typical hardened pipeline imports a pinned key from a file in the repository into a scratch keyring, verifies, and exits. That is good practice for pinning — but it means the key material has no path by which a revocation could ever reach it. The pin that protects you from key substitution also freezes you against key retirement. **The publisher's own channels disagree.** The revocation may sit on one key service while the project's website still lists the old fingerprint in its install instructions, and the release announcements from the era the key was live remain online and correct-looking. There is no authority that reconciles them. **Nothing distinguishes a revoked key from a retired one.** Revocation carries an optional reason code, and "key superseded" and "key compromised" mean very different things to a consumer — but a consumer who never fetches the revocation sees neither. ## What a revoked-but-accepted key means for the asset at risk The asset here is mostly **non-repudiation and audit truth**. Old signatures continue to validate, so an artifact signed by whoever holds that retired key remains indistinguishable, to a verifier, from a genuine historical release. If the key was retired *because* it was compromised, the holder can keep minting artifacts that a large tail of consumers accept — and nothing in those consumers' tooling will ever tell them otherwise. It is a control that silently stops being a control. ## What actually works - **Short expiry, actively extended.** Expiry is carried inside the key material that every verifier already holds, so it fails closed with no fetch required. A key valid for a year, extended deliberately each year, converts "nobody sees the revocation" into "everybody sees the expiry". The cost is a recurring maintainer ritual and a support burden when someone forgets. - **Ship the keyring as an updatable package.** Distributions do this: the trusted keys live in a package the normal update mechanism refreshes, so retirement propagates through a channel people already run. If you pin keys in pipelines, give them the same treatment — a reviewed, versioned key bundle that is updated like any other dependency. - **Publish key changes on the release channel.** Announce the new key signed by the old one, publish the revocation and the reason, and update every place the fingerprint appears, including the install docs. Assume some consumers only ever read the release notes. - **Overlap, never cut over.** Sign with both keys for a defined window before retiring the old one, so consumers who lag are not broken by the change itself. ## The operational trap on the other side The mirror image of "nobody sees revocation" is "everybody sees the roll, badly". When a fleet's package repository key is rolled, machines still pinned to the old key start failing to fetch metadata — an availability incident on the whole estate, arriving as a wall of update failures. The path of least resistance for an operator under pressure is to disable signature checking to unblock the fleet, and that switch, once it lands in a configuration-management run, is unlikely to be turned back off. So key lifecycle has to be sequenced deliberately: distribute the new key through the already-trusted keyring first, sign metadata with both keys during an overlap window, verify adoption, and only then retire the old key — so that the correct path is always faster than the workaround. ## The compact answer Revocation in OpenPGP is a *publish* operation with no *pull* on the other end. Design for expiry and for keyring updates that ride a channel consumers already run, and treat revocation as an announcement rather than as an enforcement mechanism.