Should the release-signing key be separate from my personal key?

Three reasonable answers. Same key with multiple User IDs is simplest but couples your maintainer identity with your personal identity (rotation of one rotates both). Separate keys cleanly compartmentalize but require maintaining two identities. The middle path is a single primary key with a dedicated release-signing subkey — primary stays offline (only used to certify subkeys and revoke), the subkey does the day-to-day signing and can be rotated independently. Most large projects converge on the subkey approach.

How do I publish my fingerprint so packagers can find it?

Multiple channels for redundancy: project README (in a SECURITY.md or signing section), GitHub releases page (in release notes), project website if you have one, and keys.openpgp.org for keyserver lookups. WKD on the project domain is the most robust — packager mail clients can auto-resolve your key. The Phase 3a publish-public-key guide covers each.

What about a "release signing key" lifetime — months, years, forever?

No universal rule. Linux kernel maintainers rotate every few years and publish transition statements. Smaller projects often keep the same key indefinitely. The principle: rotate when the threat model demands (suspected compromise, algorithm upgrade) or when you have a natural inflection point (major version, new maintainer). Forever-keys are fine as long as the secret material is protected.

Can I sign with multiple maintainers (quorum signing)?

OpenPGP itself doesn't do native quorum signing — there's no built-in M-of-N. Each maintainer signs the release separately, producing N detached signatures, and downstream packagers verify against the set. Some projects build tooling around this (multiple .sig files, a verification script that requires at least M to validate). For true threshold signatures, look at tools outside the OpenPGP ecosystem like Sigstore's identity-based signing or specialized threshold-crypto implementations.

Handling a key transition cleanly?

Generate the new key, sign it with the old key (cross-signing the new identity), publish the new key on keyservers and WKD, issue a transition statement signed with the OLD key announcing the rotation (with both fingerprints), revoke the old key. The transition statement is what tells the world "both keys are mine; trust transfers." See the rotate-pgp-key guide for the full procedure.

What about a "release signing key" if I step down?

Generate a revocation certificate for your key before handing the project off (or have one ready offline at any time — recommended practice). The successor generates their own key, you sign their key with yours (web-of-trust signature attesting "this person is the new maintainer"), and you revoke your key. The new maintainer's key becomes the project's signing identity going forward. Old releases remain verifiable against your (now-revoked) key — revocation doesn't un-do signatures from before the revocation.

// for / open-source-maintainers

PGP for open-source maintainers.

Your PGP key is part of your project's security infrastructure. Downstream packagers (Debian, Arch, Homebrew, Nix, distributions of every flavor) verify your signed releases. Users verify your key as part of trust. Key rotation is a public event with a transition statement. Succession is a workflow. PGPony fits into the maintainer side of that lifecycle.

Release signing Key rotation Project succession

The workflow this addresses.

You cut a release. Downstream packagers pull the tarball and check its signature against your known fingerprint before adding it to a distribution. If the signature is valid and the fingerprint is one users have learned to trust over time, the release gets packaged. If not, it doesn't ship — and that's the entire point of the system.

PGPony's role is to be the mobile and cross-platform half of your maintainer identity. The primary signing happens on a desktop with gpg (that's where your build artifacts live), but your key needs to be portable: across machines, across years, across successions. PGPony holds the same key — same fingerprint, same User IDs — and lets you work with it from anywhere.

What OpenPGP does for OSS maintenance, and what it doesn't.

// gives you

Project identity + release integrity

Signed release artifacts with detached .sig files that downstream packagers verify before distribution.
Long-term identity — your fingerprint is the canonical handle that users and distributions learn to trust.
Subkey structure — primary key offline / signing subkey for day-to-day, so you can rotate the signing material without losing identity.
Transition statements — a signed message announcing a key rotation that cryptographically links old to new identity.
Web of trust signatures — when you sign another maintainer's key, downstream tools see the chain.
Cross-platform key portability — same key works on laptop, mobile, and any successor machine.

// does not give you

Not in scope

Native quorum / M-of-N signing. Each maintainer signs separately; downstream tools aggregate. For true threshold signatures, look outside OpenPGP.
Account-level supply-chain protection. Your signature proves the release came from your key. A hijacked GitHub account publishing through your project pipeline is a different attack surface.
Reproducible builds. Signing proves authorship of the artifact. It doesn't certify that the artifact was built bit-for-bit deterministically from source.
Direct in-app key signing (one key signing another). Web-of-trust signatures and transition cross-signing both require desktop gpg — PGPony doesn't expose this operation. The keyholder is the same; only the signing UI is desktop-only.
Vendoring / distribution security beyond your signature. A packager who fails to verify your signature, or a mirror that swaps your artifact, is outside what your signing controls.

A concrete maintainer workflow.

Decide on key structure. Most projects benefit from one primary key (kept offline, ideally on an air-gapped machine or hardware token when v6.0 lands) plus a signing subkey for releases. The primary certifies subkeys and revokes; the subkey does the signing.
Generate the key. Desktop gpg is the practical choice for the primary (you'll want it offline). PGPony imports the primary or just the signing subkey — see Import a GnuPG key to your phone.
Publish the fingerprint. Add to SECURITY.md or a signing section of your README. Include it in your release notes for the first signed release. Upload to keys.openpgp.org. Set up WKD on your project domain. See Publish your public key and Set up WKD for your domain.
Sign each release. After producing the artifact:
```
gpg --detach-sign --armor my-project-2.4.0.tar.gz
# produces my-project-2.4.0.tar.gz.asc — ship both files
```
Downstream packagers verify with gpg --verify my-project-2.4.0.tar.gz.asc my-project-2.4.0.tar.gz.
Sign git tags too. git tag -s v2.4.0 -m "Release 2.4.0" and push the tag. GitHub / GitLab / Bitbucket show the Verified badge.
Document the verification process in your README or release notes. New users and packagers need to know which fingerprint to trust and how to verify. A short paragraph with the fingerprint and the gpg --verify command suffices.
Mobile workflow — use PGPony to decrypt incoming security disclosures, encrypted CVE notifications, and contributor mail. Read on the spot; respond from PGPony's Encrypt tab when needed. See Decrypt a PGP message and Send an encrypted email.
Rotate the key periodically — every 2 to 4 years, or on suspected compromise, or at a natural project inflection point. The rotation includes generating a new key, cross-signing it with the old, publishing a transition statement, and revoking the old. See Rotate your PGP key safely for the full procedure.

Project succession.

When you step down or hand off the project to a new maintainer, the signing identity has to transition cleanly. The pattern:

New maintainer generates their own key on their own infrastructure. They have the secret; you don't.
You sign their key with yours, asserting publicly that you trust this person to take over signing responsibility. Done with desktop gpg: gpg --sign-key NEW_MAINTAINER_FINGERPRINT.
You publish a transition statement signed with your key announcing the handover and the new fingerprint. See the rotation guide for the template — the structure is identical, just framed as succession instead of rotation.
The new maintainer publishes their key on keyservers and via WKD on the project domain.
Your key is either revoked (if you want to terminate the identity) or simply marked as no longer the project signing identity (if you want to keep it for your own use).
Old releases remain verifiable against your key — revocation doesn't un-do signatures from before the revocation. The project's history is preserved.

Is PGPony right for OSS maintenance?

// yes if

You maintain a project that benefits from signed releases
Downstream packagers verify your signatures
You want mobile access for encrypted disclosures and contributor mail
You want the same key across multiple machines you maintain from
Standard subkey structure (primary + signing subkey) fits your model

// not the right tool if

You need true M-of-N quorum signing for releases
Hardware-token signing is mandatory today (planned in v6.0)
Your project uses Sigstore / identity-based signing instead
You want the signing infrastructure fully automated with no human key custodian

Common questions from maintainers.

Release-signing key separate from my personal key?

Three reasonable answers. Same key with multiple User IDs is simplest but couples maintainer and personal identity. Separate keys cleanly compartmentalize but require maintaining two identities. The middle path is a primary key with a dedicated release-signing subkey — primary offline, subkey for day-to-day signing. Most large projects converge on the subkey approach.

How do I publish my fingerprint?

Multiple channels: project README (SECURITY.md), GitHub releases page, project website, keys.openpgp.org, and WKD on the project domain. The Phase 3a publish-public-key guide covers each.

Key lifetime — months, years, forever?

No universal rule. Linux kernel maintainers rotate every few years with transition statements. Smaller projects often keep the same key indefinitely. Rotate when threat model demands (compromise, algorithm upgrade) or at a natural inflection point (major version, new maintainer).

Multiple maintainers / quorum signing?

OpenPGP doesn't do native M-of-N. Each maintainer signs separately, producing N detached signatures; downstream packagers verify against the set. For true threshold signatures, look at Sigstore or specialized threshold-crypto implementations.

Clean key transition?

Generate new key, sign it with old key (cross-signing the identity), publish new on keyservers and WKD, issue a transition statement signed with OLD key, revoke the old. See rotate-pgp-key guide for the full procedure.

What happens to old releases when I rotate?

Old releases stay verifiable against the (now-revoked) old key — revocation doesn't un-do signatures from before the revocation. Project history is preserved. New releases use the new key.

Related material.

Get PGPony

Free OpenPGP encryption for iOS and Android. No accounts, no tracking.

Download on the App Store Get it on Google Play