PGP for developers.

The workflow this addresses.

You sign commits and releases with PGP because your project's downstream packagers and your users care about authenticity. The key lives in gpg on your laptop because that's where git runs. But your mobile workflow exists too: a security disclosure lands while you're away from the desk; a maintainer messages you encrypted; an incident response starts at 11pm on a Saturday. You want to be able to read those messages without SSHing in from your phone.

PGPony holds the same key your laptop has — same fingerprint, same User IDs — secured in iOS Keychain or Android Keystore. You decrypt on the phone; you keep signing on the laptop (since that's where the source lives). The two halves of the workflow stay in sync because they're literally the same key.

What OpenPGP does for you here, and what it doesn't.

A concrete workflow.

1. Decide on key structure. Single identity covers most developers — one primary key, signing + encryption subkeys, multiple User IDs (work + personal) if you want one fingerprint everywhere. Separate keys per identity if you want clearer compartmentalization.
2. Generate the key. If you don't already have one, generate in PGPony (iPhone guide, Android guide) or via desktop gpg. Ed25519 + Curve25519 is the modern default — small keys, fast generation, universal support.
3. Import to desktop gpg. Export from PGPony, transfer to your dev machine, gpg --import your-key.asc. See Sign Git commits with PGP for the full sequence.
4. Configure git.

   git config --global user.signingkey YOUR_FINGERPRINT
   git config --global commit.gpgsign true
   git config --global tag.gpgsign true
   git config --global user.email you@yourdomain.com

   The user.email must match a User ID on your key or platforms will show "Unverified".
5. Upload the public key to each forge. GitHub: Settings → SSH and GPG keys. GitLab: Preferences → GPG Keys. Bitbucket: Personal settings → GPG keys. The Verified badge appears on commits from matching emails.
6. Publish your fingerprint in your README, your project's release page, and any contact-info section of your site. Downstream packagers and users verify against this. See Publish your public key.
7. (Optional) Set up WKD on your project domain so maintainers and users can encrypt to you without manual key lookup. See Set up WKD for your domain.
8. For release signing, the same desktop gpg signs your tarballs:

   gpg --detach-sign --armor my-release-1.0.tar.gz
   # produces my-release-1.0.tar.gz.asc — ship both

   Downstream packagers verify with gpg --verify my-release-1.0.tar.gz.asc my-release-1.0.tar.gz.
9. On mobile, use PGPony to decrypt security disclosures and encrypted mail from maintainers and contributors. The Decrypt tab handles both encrypted text and clearsigned-only messages.

CI / GitHub Actions signing.

For automated release signing, generate a separate signing subkey of your primary key (or a separate dedicated key) and install only that on your CI runner. The CI never sees your primary secret key.

# On desktop gpg, add a signing subkey
gpg --edit-key YOUR_FINGERPRINT
gpg> addkey
# pick: 4 (RSA sign only) or 10 (ECC sign only)
gpg> save

# Export ONLY the secret subkey for CI
gpg --export-secret-subkeys --armor SUBKEY_ID! > ci-signing.asc
# store as an encrypted CI secret (GitHub Actions Secrets, GitLab CI Variables, etc)

The ! after the subkey ID is required by gpg's export syntax. The primary secret stays on your machine and in PGPony. If the CI is ever compromised, you revoke only the subkey — the primary identity stays intact.

Is PGPony right for your dev workflow?

Common questions from developers.

Related material.