Affected: at least GnuPG versions 2.4.4 2.4.7(=Debian 13 stable) 2.4.8 2.5.18

Summary: if gpg is told to update its keys from a key server via the following command, the updates are aborted with an error in many cases:

gpg --keyserver-options no-self-sigs-only,no-import-clean --keyserver hkps://example.com/ --refresh-keys

We're using a DIY key server which follows the HKPS-specifications. We're pretty sure this is an issue at client side. Other GnuPG implementations are just working fine.

According to an analysis of https://github.com/gpg/gnupg, the issue is:

• Keys are fetched in chunks. For 40-hex fingerprints, that is typically about 21 keys per chunk.
• Within a chunk, keys are tried one by one.
• If at least one key in that chunk is fetched successfully, that chunk counts as success, and GnuPG proceeds to the next chunk.
• If a chunk returns no data at all, meaning none of the keys in that chunk could be fetched, keyserver_get stops there and the refresh aborts for all later chunks.

In detail:

• g10/keyserver.c:1215 calls g10/keyserver.c:1598 for the batch.
• g10/keyserver.c:1609 processes the batch chunk by chunk and stops on the first chunk error.
• Inside one chunk, dirmngr's dirmngr/ks-action.c:361 fetches keys one by one, and a missing key does not immediately abort the others; it saves the error and continues.
• But if that chunk produces no data overall, dirmngr returns GPG_ERR_NO_DATA at dirmngr/ks-action.c:445, and then keyserver_get aborts further chunks at g10/keyserver.c:1615.

So if this analysis holds true: gnupg fetches the keys in batches (chunks) of, e.g., 21 keys per batch. If all keys of a single batch of 21 keys do not have a representation on the key server, gnupg aborts the overall update process with an error, not fetching all the key updates from the server.

I've implemented a workaround script to mitigate the issue until the bug is fixed in all relevant gnupg versions: https://codeberg.org/publicvoit/my-domain-gpg-refresh-keys.sh

HTH