Back Up GnuPG Ownertrust When lspgpot Comes Up Empty

lspgpot on modern GnuPG prints warnings instead of trust records, which looks like data loss but is not. You just need the command GnuPG actually supports for the backup. On this machine the installed package is gnupg-utils 2.4.4-2ubuntu17.6, with GnuPG 2.4.4.

Allow about ten minutes. You need a shell and access to the GnuPG home directory whose trust you want to preserve. This guide reads keyring and trust-database state; it does not change either. The backup file contains key fingerprints and trust decisions, so treat it as security-sensitive even though it holds no private keys.

1. Check the installed helper

Confirm which executable will run and record the package version:

$ command -v lspgpot
/usr/bin/lspgpot
$ dpkg-query -W -f='${Package} ${Version}\n' gnupg-utils
gnupg-utils 2.4.4-2ubuntu17.6
$ gpg --version | head -n 2
gpg (GnuPG) 2.4.4
libgcrypt 1.10.3

Your package revision can differ. The important point is that lspgpot is a shell script installed by gnupg-utils, not a separate trust-database implementation. Its manual page describes one invocation, lspgpot, with no documented options.

Checkpoint: continue only if command -v points at the helper you intended to test. If it finds nothing, install or enable the normal GnuPG utilities through your distribution's package process rather than copying a script from an unknown source.

2. Run lspgpot without changing anything

Run it with no arguments and keep standard error visible:

$ lspgpot
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: processing message failed: Unknown system error
# Ownertrust listing generated by lspgpot
# This can be imported using the command:
#    gpg --import-ownertrust

That warning and the two GnuPG errors are the relevant result on this installed version. The helper still exits successfully, but prints no fingerprint and no trust value. Do not treat the header alone as a backup: a zero exit status is not enough here, because the wrapper's final awk process can mask a failure from the command it runs.

Passing a listing command exposes the same compatibility boundary more clearly:

$ lspgpot --list-keys
# Ownertrust listing generated by lspgpot
# This can be imported using the command:
#    gpg --import-ownertrust

On this GnuPG release, the machine-readable key listing does not supply the legacy records this script filters for, so a key can exist with no ownertrust line ever appearing in lspgpot's output. The exact diagnostic may vary with the keyring, but an empty data section is not evidence every ownertrust value is unset.

3. Use GnuPG's supported export for the backup

GnuPG documents --export-ownertrust for sending ownertrust values to standard output. Write it to a new file in a directory with suitable permissions:

$ umask 077
$ gpg --batch --export-ownertrust > /path/to/ownertrust-backup.txt
$ test -s /path/to/ownertrust-backup.txt && echo 'backup is non-empty'
backup is non-empty

Replace /path/to/ownertrust-backup.txt with a real destination, such as $HOME/gnupg-ownertrust-2026-09-24.txt. The redirection creates or truncates the destination before gpg runs, so if the file already matters, pick a new name or copy it aside first. Do not use sudo for a personal keyring: it can make root's empty or different GnuPG home the source of the backup instead of yours.

Inspect the result without publishing it:

$ sed -n '1,8p' /path/to/ownertrust-backup.txt
# List of assigned trustvalues, created Thu Sep 24 23:15:38 2026 BST
# (Use "gpg --import-ownertrust" to restore them)
0123456789ABCDEF0123456789ABCDEF01234567:6:
$ awk -F: '$1 !~ /^#/ && NF { print "ownertrust records:", count++ + 1 }' /path/to/ownertrust-backup.txt
ownertrust records: 1

Fingerprint values will be different on your system. A record has a fingerprint, a numeric trust value, and a trailing field, all separated by colons. Keep the file private: the comments are handy during recovery, but the fingerprint lines are the data you actually need.

4. Verify the backup against a second export

Export to a temporary file and compare the data lines. The generated comment includes a timestamp, so compare records rather than whole files:

$ second=$(mktemp)
$ trap 'rm -f "$second"' EXIT
$ gpg --batch --export-ownertrust | awk -F: '$1 !~ /^#/ && NF' > "$second"
$ awk -F: '$1 !~ /^#/ && NF' /path/to/ownertrust-backup.txt | diff -u - "$second"
$ echo $?
0

The comparison reads the trust database again and makes no changes. Status 0 means the records in the saved file match the second export. Non-zero means stop and investigate the keyring or destination before you replace anything. The temporary file disappears when this shell exits; the backup does not.

5. Know how recovery would work

Importing ownertrust changes the selected GnuPG trust database, so do not run it as a casual test against your working keyring. If you ever need to restore a backup, select the intended GnuPG home, make a fresh backup of its current ownertrust first, then import deliberately:

$ gpg --batch --import-ownertrust /path/to/ownertrust-backup.txt

Warning: GnuPG overwrites existing ownertrust values with the imported ones. There is no undo command here: recovery means importing the pre-change backup you made first. If a trust database is severely damaged, follow the official recovery procedure and understand that deleting trustdb.gpg is destructive. Do not delete it just because lspgpot printed an empty result.

Done means