OpenPGP certificate manager · Linux and macOS

Your certificates,
in a window.

A window that lists your certificates and lets you generate, import, export, sign, encrypt, decrypt and verify without touching a command line.

Rust throughout · Slint for the GUI · Sequoia for OpenPGP
no webviewno Qtno C++no gpg subprocess

Read the source
cargo run -p rpgp-gui

The window

rPGP
rPGP
All certificates7 My keys2 Other people5
Sign / Encrypt Decrypt / Verify Notepad About
Search name, e-mail or fingerprint Mine first Import Look up Export New key pair
  • Ada Lovelace ada@analytical.engine verifiedsecret keyvalid CSE · until 2028-08-10
  • Grace Hopper grace@navy.mil verifiedsecret keyvalid CSE · until 2028-08-10
  • Alan Turing alan@bletchley.uk verifiedvalid CSE · until 2028-08-10
  • Barbara Liskov barbara@substitution.org verifiedvalid CSE · until 2028-08-10
  • Katherine Johnson katherine@nasa.gov verifiedvalid CSE · until 2028-08-10
  • Radia Perlman radia@spanning.tree partly verifiedvalid CSE · until 2028-08-10
  • Linus Torvalds linus@kernel.org valid CSE · until 2028-08-10 not authenticated
Ada Lovelace ada@analytical.engine
valid secret key
Fingerprint
4E34 2E8E FC1F 755F F26F 9296 4285 1AE3 2ED6 D571 D110 9414 3039 6EE2 31C6 789D
Key ID
4E342E8EFC1F755F
Algorithm
Ed25519
Created
2026-08-11
Expires
2028-08-10
Usage
CSE
User IDs
Ada Lovelace <ada@analytical.engine>

The web of trust confirms this identity.

Trust root

Your own keys are always trust roots.

7 certificate(s), 2 with a secret key

Two different questions get asked
about a certificate.

rPGP shows both, because confusing them is how people end up trusting the wrong key.

validexpiredrevoked

Validity

Is the certificate internally sound? Self-signatures check out, not expired, not revoked. This says nothing about who the certificate belongs to.

verified partly verified

Authentication

Does the name on it belong to the person you think? Computed by sequoia-wot from the certifications in your store.

The demo store's web of trust Ada and Grace hold their own secret keys, so they are trust roots. Ada has certified Alan in full, and certified Barbara as a trusted introducer; Barbara has in turn certified Katherine, who is therefore authenticated one hop out. Ada certified Radia only partially, so Radia is partly verified. Nobody has vouched for Linus, so his certificate is valid but unauthenticated. full introducer partial full AL Ada GH Grace AT Alan BL Barbara RP Radia LT Linus KJ Katherine
verified Ada, Grace, Alan, Barbara and Katherine. partly verified Radia. Linus gets no badge at all — an unverified stranger in the list would be noise, and the details pane spells it out anyway.

A perfectly valid certificate from a stranger is unauthenticated, and a key you confirmed years ago stays authenticated after it expires.

Certifying always names one user ID — OpenPGP has no way to vouch for a certificate as a whole — so the dialog lists them and you tick the ones you actually checked. Mark someone a trusted introducer and the keys they certify count too. The graph is rebuilt on every store reload rather than cached, which is fine for the sizes tested and will need revisiting for a keyring of thousands.

rPGP never sees a PIN.

Card keys are reached through your own gpg-agent, not by talking to the reader. The agent runs your own pinentry.

Not a preference — the only way in

scdaemon holds the card with an exclusive PC/SC transaction, so a second process asking the reader directly gets SCARD_E_SHARING_VIOLATION.

Two things follow, both good

rPGP never sees a PIN, and there is no PC/SC dependency. Signing, certifying and decrypting all work on a card.

Your certificates are not locked in this app.

Public certificates

$XDG_DATA_HOME/pgp.cert.d

A pgp-cert-d directory — the same layout sq uses, so they are shared with other Sequoia tooling rather than locked in here. Override with RPGP_CERT_STORE.

Secret keys, deliberately elsewhere

$XDG_DATA_HOME/rpgp/secrets/

cert-d is a store of public certificates; a transferable secret key in it would be readable by every tool that scans the directory. These are 0600 in a 0700 directory, tightened every time the store is opened rather than only when a key is written. A key generated with a passphrase is encrypted with it; a key generated without one is not, and then the file permissions are all that protects it.

One-way, and public.

The signature becomes part of the certificate, and anyone who already has a copy keeps it forever.

A revocation certificate is written at key generation, because it cannot be recreated afterwards — applying it needs neither the secret key nor its passphrase, since it was signed while the key was in hand.

Choosing secret key may be compromised makes it a hard revocation, which also invalidates every certification the key ever issued — so anyone it had authenticated drops back to unverified.

rPGP does not read ~/.gnupg, and nothing it does will disturb it.

Public certificates need no export at all: point Import at ~/.gnupg/pubring.kbx. It is GnuPG's Keybox container rather than an OpenPGP keyring, and it is recognised by its magic bytes rather than its name. Secret keys still need exporting, since GnuPG keeps them in gpg-agent's own format:

gpg --export-secret-keys --armor > /tmp/rpgp-secret.asc

This copies secret key material: the keys then exist twice, under two different protections — gpg-agent's, and rPGP's weaker on-disk one. Delete the file afterwards. Smartcard keys cannot come across, and ownertrust has nowhere to go.

There are no release binaries yet.

Build from source. It needs the Cap'n Proto compiler (capnp) installed.

cargo run -p rpgp-gui

To try it with content in it, seed a throwaway store — it writes only inside the XDG_DATA_HOME you give it. That is where the certificates above come from.

XDG_DATA_HOME=/tmp/rpgp-demo cargo run -p rpgp-core --example seed-demo-store

github.com/jzbz/rpgp