Hello,
this was reported in Debian BTS by Seth McDonald, I have verified that it applies to 2.4.9. Original report follows.
It appears that when GnuPG generates keys with the --dry-run option,
rather than discarding any generated keys, it creates and stores new
private keys on disk. However, these keys cannot be accessed via the
keyring, meaning they effectively just take up disk space with no use.
Consider the following sequence of shell commands (with some irrelevant
output removed or replaced).
$ mkdir -m u=rwx,go= ~/gpg-test $ export GNUPGHOME=~/gpg-test $ gpg --dry-run --yes --quick-generate-key "hello <hello@domain.tld>" gpg: keybox '/.../gpg-test/pubring.kbx' created [...] gpg: /.../gpg-test/trustdb.gpg: trustdb created gpg: directory '/.../gpg-test/openpgp-revocs.d' created gpg: revocation certificate stored as '/.../gpg-test/openpgp-revocs.d/XXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.rev' public and secret key created and signed. pub ed25519 YYYY-MM-DD [SC] [expires: YYYY-MM-DD] XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX uid hello <hello@domain.tld> sub cv25519 YYYY-MM-DD [E] $ gpg --check-trustdb gpg: Note: ultimately trusted key XXXXXXXXXXXXXXXX not found gpg: no ultimately trusted keys found $ gpg --list-public-keys $ gpg --list-secret-keys $ ls $GNUPGHOME openpgp-revocs.d private-keys-v1.d pubring.kbx trustdb.gpg $ ls $GNUPGHOME/openpgp-revocs.d $ ls $GNUPGHOME/private-keys-v1.d YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY.key ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.key
After the key XXXXXXXXXXXXXXXX is said to be generated, gpg is unable to
find it. This is expected, due to the use --dry-run.
However, the $GNUPGHOME/private-keys-v1.d directory is filled with two
keys - YYYYYYYYYYYYYYYY and ZZZZZZZZZZZZZZZZ - neither of which are
specified by the key generation nor can be reached via the keyring. To
my understanding, these files have no use and should not have been left
by gpg.