Your project signs releases with a long-lived PGP key and a team proposes keyless signing. How do you decide?

## Start by naming who verifies This decision is almost never settled by comparing cryptography. It is settled by asking who your consumers are and what they run at verification time, because a signature nobody checks has identical value in both models: zero. Three consumer profiles pull different ways: - **Distribution and enterprise packagers.** They have pinned keyrings, air-gapped or egress-restricted build hosts, and long-lived process. They want offline verification and they want the key not to change often. - **Container and platform consumers.** They verify at admission or at pull, on hosts with network access, and are comfortable with a policy that names a builder identity rather than a person. - **Individual developers.** Mostly verify nothing, in either model, unless the ecosystem's default tooling does it for them. ## What the long-lived key genuinely gives you - **Offline verification.** Artifact plus keyring is sufficient. No service must be reachable, at signing or at checking. This is the property that keeps the model alive in regulated, air-gapped and long-horizon environments. - **Longevity.** A ten-year-old artifact still verifies against the key you archived, which matters for forensic and reproducibility questions during an incident. - **Ubiquity.** Every packager already has the tooling and the habits. And what it costs: - **Custody for years.** A secret that must survive laptops, staff turnover and CI secret stores for the life of the project. - **Discovery unsolved.** The verifier still has to learn which key is yours, on a channel independent of your website. - **Revocation nobody sees.** Retiring the key does not reliably reach anyone who already imported it. - **Human ceremony.** Release signing depends on a person being available and doing it correctly. ## What the keyless model gives you - **No durable secret.** The signing key is generated per operation and discarded; there is nothing to steal from a laptop or read out of a secret store months later. - **Identity binding to a workload.** The signature is tied to a build identity issued at signing time rather than to whoever holds a file. That is a better match for automated releases than "the maintainer's key that CI happens to have". - **A public record.** Signing events land in an append-only transparency log, so issuance is auditable after the fact and unexpected signing activity is at least discoverable. And what it costs: - **New online dependencies.** An identity provider must be reachable at signing time, and the trust root — the material a verifier needs to check the certificate chain and the log — comes from a service you do not run. It can be bundled for offline verification, but bundling it is an operational task with its own freshness problem. - **A policy you must now write.** Trust moves from "is this the maintainer's key" to "is this the expected builder identity and workflow". That is a real improvement in expressiveness and a real new artifact to maintain, review and keep correct. - **Downstream tooling.** Consumers who verify today with standard PGP tooling need something new. Some of them are exactly the consumers you least want to break. - **Availability coupling.** Your release can now be blocked by an outage in something outside your control. ## The organisational layer, which is where the answer lives - **Measure verification before you invest.** A rough proxy exists: compare downloads of the signature files against downloads of the artifacts. If the ratio is a fraction of a percent, your bottleneck is not the signing technology, and the higher-leverage work is making verification the default in the paths your consumers actually use. - **Cost the custody honestly.** A decade of key custody has an owner, a rotation plan and an audit story. If nobody in the org can name that owner today, the long-lived key is already failing, and that is a strong argument to move. - **Contracts and compliance.** A customer or regulator may require a specific artifact. Check before choosing, and expect to owe *both* for a while. - **You will run both.** Sign with the existing key and with the new flow for an announced overlap window, publish both, tell consumers the retirement date, and keep the old key valid until adoption telemetry says it is safe. The failure mode to design against is a cutover that breaks pinned consumers, because their fastest workaround is to stop verifying, and that setting rarely gets reverted. ## The answer that lands "It depends on who verifies and what they can run at verification time. Keyless removes long-term key custody and gives me an auditable record; the long-lived key gives my air-gapped and packager consumers verification with no online dependency. So I would measure verification coverage first, publish both through an overlap window, and only retire the old key when the consumers I care about have moved."