What rPGP keeps,
and what it sends.

ON YOUR COMPUTER

What rPGP keeps, and where.

Apart from files you ask it to write, rPGP keeps all of its own files in two directories: one for public certificates, and its own for secret keys and everything else.

Setting RPGP_CERT_STORE moves the certificate directory. PGP_CERT_D, which other Sequoia tools read for the same purpose, is not honoured.

Public certificates

The certificate directory is a standard pgp-cert-d store, the one sq and other Sequoia tools use by default, so on a native build they see what you import and rPGP sees theirs. The Flatpak keeps its own, separate from the host's.

It holds the certificates you create or import, public halves only: secret key material is stripped before anything is written there. That includes the names and e-mail addresses on them, and the certifications you make, local ones included, which are never exported or published.

Sequoia's certificate store keeps two SQLite databases in the same directory, created the first time rPGP starts even if you do nothing else, and SQLite's -wal and -shm files can sit beside them. One is an index of every certificate's fingerprint, key IDs, user IDs, e-mail addresses and domains. The other is a cache that can hold a one-way hash of each signature rPGP has checked, with the day it was last used: signatures on certificates, including those a lookup returns before you import anything, and signatures on files and messages you verify. A hash is not the signature, but anyone who has the same signature and what it covers can tell from the cache whether rPGP on this computer has checked it. Their names contain your computer's host name, as in _sequoia_cert_store_index_v1_on_<hostname>.sqlite.

rPGP does not restrict who can read this directory. Whether other accounts on the same computer can read it depends on your system's default permissions for new files.

On Windows it sits in roaming AppData. Where roaming profiles or folder redirection are in use, that folder, index and cache included, is kept on a server your organisation's domain controls: a roaming profile copies it there when you sign out and back when you sign in, and folder redirection keeps it there. That is Windows moving the files, not rPGP. Secret keys are kept in local AppData, which does not roam, for exactly this reason.

Secret keys

One file per key, secrets/<FINGERPRINT>.pgp in rPGP's own directory. On Linux and macOS each file is created readable only by you (mode 0600) in a directory only you can open (0700), and those modes are applied again every time rPGP opens its store. On Windows each file and directory gets an access control list with a single entry, for your own account.

Whether a key is encrypted depends on how it arrived:

• Generated with a passphrase: encrypted with it, using Sequoia's defaults: an iterated and salted SHA-256 key derivation, then AES-256 for version 4 keys, or AES-128 in OCB mode for version 6 keys.
• Generated with the passphrase left empty (it is optional): stored unencrypted. File permissions are then all that protects it.
• Imported: each secret key keeps the protection it arrived with, encrypted or not. When you import a key rPGP already holds, the two copies are merged key by key and an imported secret replaces the stored one, so importing an unencrypted backup replaces a protected key with an unprotected one. (After 0.1.3, a GnuPG stub, which holds no key, no longer replaces a real one.)

rPGP has no way to add, change or remove a passphrase once a key is stored, and no command that exports a secret key. Using a protected key decrypts a copy in memory for that one operation, and rPGP writes no decrypted copy to disk. rPGP does not lock its memory, though, so the operating system can move parts of it to swap or a hibernation file, including a key or passphrase in use or a message decrypted in the Notepad.

rPGP does not save passphrases: not to a file, and not to the macOS keychain, the Secret Service or Windows Credential Manager. What you type stays in the app's memory, where the interface toolkit keeps copies that cannot be wiped, and like the rest of that memory it can reach swap.

The secret halves of keys held by gpg-agent or on a smartcard stay there. rPGP never copies them; see gpg-agent below.

Revocation certificates

When rPGP generates a key, it also writes a revocation certificate for it to revocations/<FINGERPRINT>.rev, readable only by you. It is not encrypted, and anyone who has it can revoke your key. Deleting the key leaves it in place, and rPGP has no way to delete it. rPGP can save a copy to a place you pick.

Lists, settings and logs

Beside those, rPGP keeps three plain-text lists of fingerprints, one per line and readable only by you: trust-roots, imported-secrets and sha1-accepted. trust-roots and sha1-accepted are the only choices it remembers, and imported-secrets records which secret keys you imported rather than generated.

rPGP has no settings, preferences, recent-files or window-state file. rPGP's own environment variables are RPGP_CERT_STORE, RPGP_KEYSERVER and RPGP_ALLOW_DEBUG. Others matter too: XDG_DATA_HOME in the table above, GNUPGHOME and the display settings under gpg-agent, and the proxy and certificate variables described under Network.

These are rPGP's own files. The operating system and desktop can keep records of their own that rPGP neither writes nor reads, such as a list of files recently picked in file dialogs, saved window state or graphics caches. A backup of your home folder that includes these directories copies your secret keys and revocation certificates with it.

rPGP writes no log files. It prints a few messages to standard error: that it is falling back to, or restarting on, the software renderer; that the crash-dump protections below could not be applied, or that RPGP_ALLOW_DEBUG has turned them off; that the application ID could not be set; or a fatal error at startup, which may name a store path. rPGP's own messages contain no key material, addresses or passphrases. A crash also prints the failing library's own message. Where standard error goes is up to whatever started rPGP: a desktop launcher may record it in the system log, such as the systemd journal. The Windows release build has no console, so there it is discarded unless whoever started rPGP redirected it.

Files you create

Sign, Encrypt and Decrypt write their result next to the input file, under a name derived from it: notes.txt is encrypted to notes.txt.asc or signed as notes.txt.sig, and decrypting notes.txt.asc gives notes.txt. If the name is taken, a free one is chosen.

Encrypted files and signatures get ordinary permissions, and on Windows every result takes its folder's permissions. Encrypted and decrypted results are written first as a .part file beside them and renamed when complete. A signature is written straight to its name, except one saved through the Flatpak's save dialog after 0.1.3, which is staged the same way.

Exporting a certificate writes only its public part, without local certifications, to a file you pick. Import reads only files you pick.

rPGP does not use the system's temporary directory. It writes its own files beside their final place and renames them into it.

Deleting

Deleting a certificate removes its file and, once you confirm that too, its secret key file. There is no secure erase: files are unlinked, not overwritten. Some things stay behind:

• its revocation certificate;
• its rows in Sequoia's index: fingerprint, key IDs, user IDs, e-mail addresses and domains;
• any hashes of its signatures in Sequoia's signature cache;
• its entry in imported-secrets;
• any <FINGERPRINT>.pgp.unreadable copy (or .unreadable.1, .unreadable.2 and so on). When a stored secret key file cannot be read at the moment rPGP needs to write that key, rPGP renames it aside rather than overwriting it, and it stays until you remove it.

To remove everything rPGP has stored, delete both directories in the table above yourself. On a native build the certificate directory is shared with sq and other Sequoia tools.

Crash dumps

On Linux rPGP turns off core dumps and marks its process as not dumpable, which also stops other programs running as you from attaching a debugger to it. On macOS it turns off core dumps; the system's own crash reporter can still write a report of the crash, which is not a copy of its memory, and sends it to Apple only if you share analytics with Apple or choose to send it. On Windows it does neither and leaves Windows Error Reporting as it is, so a crash dump, if Windows makes one, could contain key material or a passphrase in use at the time, and Windows may send its report to Microsoft according to your diagnostic data settings. Setting RPGP_ALLOW_DEBUG turns these protections off.

ON THE SAME COMPUTER

What rPGP talks to without the network.

gpg-agent

Smartcard keys, and keys GnuPG holds, are used through your own gpg-agent. Each time rPGP loads its list of certificates (at startup, on Refresh and after every change), it asks the agent which keys it holds. It finds the agent by running GnuPG's gpgconf, and if none is running it may have gpgconf start one, in which case GnuPG may create files of its own, such as its socket directory. The connection is to a local socket, and leaves the computer only if that socket is itself forwarded from another one, as SSH can do.

Listing keys sends no certificates: rPGP asks for the agent's list of key grips and matches them itself. Signing or decrypting with an agent key sends which key to use, the hash to sign or the encrypted session key, a description for the agent's PIN prompt, and the terminal and display settings that prompt needs (GPG_TTY or the terminal name, TERM, DISPLAY, XAUTHORITY, DBUS_SESSION_BUS_ADDRESS).

You type the PIN or passphrase into the agent's own pinentry, so it never passes through rPGP, and how long it is cached is up to your agent configuration. rPGP never sends the agent a passphrase or a key, and never imports, exports or deletes keys there.

rPGP itself does not read ~/.gnupg; GnuPG's own programs use it as usual. GnuPG's pubring.kbx is read only if you pick it in Import.

The Flatpak is given the host's GnuPG socket directory, /run/user/<uid>/gnupg, so that it can use the host's agent, and is not given ~/.gnupg. That directory also holds GnuPG's other sockets, such as the ssh-agent and scdaemon ones; rPGP connects only to the agent's main socket.

The desktop

File dialogs. On Linux, rPGP asks the desktop portal's file chooser over the session bus, or runs zenity where there is no portal. It also reads the light or dark appearance setting from the portal. The Flatpak has no access to your home directory: outside its own data directory, it reaches only the files you pick and the GnuPG sockets above.

Clipboard. rPGP's Copy buttons copy only when pressed. Its text fields also copy a selection with Ctrl+C, and on Linux any text you select in one with the mouse goes to the primary selection, which other programs can read, as in most apps. rPGP reads the clipboard only when you paste into a field (on Linux, a middle-click pastes the primary selection), and never clears it. Fingerprints, key IDs and user IDs are copied as ordinary text.

In both, the Notepad's input box, which may hold a message you are about to encrypt, behaves like any other text field.

Accessibility. rPGP describes its window to the system's accessibility services (AT-SPI on Linux, UI Automation on Windows, the accessibility interface on macOS) so that screen readers can read it. That includes user IDs, fingerprints and Notepad text. Passphrase fields are described as empty.

OTHER PEOPLE'S SERVERS

Where your requests end up.

The app sends nothing to the rPGP project. Everything it sends goes to the servers below, under their own policies.

keys.openpgp.org

The default keyserver, a community-run service. It receives lookups that WKD does not answer, lookups without an @, WKD lookups for domains that delegate their WKD to it, and everything you publish. Its privacy policy says, among other things, that it:

• logs all incoming requests for 30 days, with IP addresses anonymized for storage;
• processes public key material, self-signatures and revocation signatures to provide the service, and may hand that data to third parties on request for development or research;
• publishes an e-mail address only after its owner confirms it by e-mail, and lets it be found by the exact address only, not by name;
• strips user IDs without an e-mail address, and photos, on upload, and does not store them;
• lets you remove your addresses with its "manage" tool, and deletes a certificate on request to its support address; anyone can upload it again unless you also ask support to banlist it.

Everyone else

• WKD hosts are whichever servers the DNS of the address's domain names: usually run by or for the domain's owner, but possibly a hosted WKD service. rPGP cannot tell you their policies.
• A keyserver you choose with RPGP_KEYSERVER works under its operator's policy.
• Any host a server redirects to receives what is described under redirects.
• Your DNS provider and network see the host names and your IP address, as described above.
• Your operating system may check the app itself when you first open it, as Gatekeeper does on macOS and SmartScreen on Windows, and those checks can contact Apple or Microsoft. They are the system's, not rPGP's, and are not covered here.
• Downloads. Every package is downloaded from GitHub Releases, under the GitHub Privacy Statement. Installing the Flatpak bundle fetches its runtime from the Flatpak remotes you have configured. winget, Homebrew and Flatpak are separate tools, and what they collect is not covered here.

CONTACT

Questions, and changes.

Questions about this page, or anything the app does that it does not describe, go to the issue tracker at github.com/jzbz/rpgp/issues. Issues are public, so leave out anything you would not publish.

This policy is effective from 2026-09-28. It covers rPGP 0.1.3 and the unreleased code after it, as of commit c1f0b54. When a release changes anything described here, this page changes with it, and so does the date. What it says about the app can be checked against the source.