Validity
Is the certificate internally sound? Self-signatures check out, not expired, not revoked. This says nothing about who the certificate belongs to.
OpenPGP certificate manager · Linux and macOS
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
cargo run -p rpgp-gui
OPERATIONS
Sign / Encrypt Decrypt / Verify Notepad AboutCERTIFICATE
TRUST
The web of trust confirms this identity.
Trust rootYour own keys are always trust roots.
AUTHENTICATION
rPGP shows both, because confusing them is how people end up trusting the wrong key.
Is the certificate internally sound? Self-signatures check out, not expired, not revoked. This says nothing about who the certificate belongs to.
Does the name on it belong to the person you think? Computed by
sequoia-wot from the certifications in your store.
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.
SMARTCARDS
Card keys are reached through your own gpg-agent, not by
talking to the reader. The agent runs your own pinentry.
scdaemon holds the card with an exclusive PC/SC
transaction, so a second process asking the reader directly gets
SCARD_E_SHARING_VIOLATION.
rPGP never sees a PIN, and there is no PC/SC dependency. Signing, certifying and decrypting all work on a card.
WHERE THINGS LIVE
$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.
$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.
REVOCATION
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.
COMING FROM GNUPG
~/.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.
BUILD AND RUN
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