If you're using #gnupg with a keyserver for "gpg --refresh-keys" and you're running into the bug of getting aborted with "No data", this script is a good workaround for updating your keys of a single email domain using a (organization) key server:

https://codeberg.org/publicvoit/my-domain-gpg-refresh-keys.sh

Background: gnupg fetches keys in chunks (batches) and if a single chunk doesn't contain a single address found on the key server (because you got the keys elsewhere), the whole update process is aborted. 🤦‍♂️

#gpg #OpenPGP

my-domain-gpg-refresh-keys.sh

This shell script updates the OpenPGP keys from a key server for keys of a specific email domain only in order to circumvent a bug in gnupg which causes "--refresh-keys" to abort with "No data".

Codeberg.org
@publicvoit hey, keyserver developer here. đź‘‹ Does this happen when querying over hkp or just ldap?

@andrewg The command is:
gpg --keyserver-options no-self-sigs-only,no-import-clean --keyserver hkps://example.com/ --refresh-keys
... using our company key server.

The server component is integrated into our company backend and thus, no standard FOSS OpenPGP server product.

It's implemented according to the standards and therefore, each standard-conform implementation should have that issue with gnupg versions: 2.4.4 2.4.7 2.4.8 2.5.18

In our understanding, this is a bug in gnupg (client).

To simulate the behavior, you need a (test) setup with number of keys > chunk size (need to analyze gnupg source for that) + at least 1 key where this is the only key matching a keyserver entry and all the others not.

HTH

@publicvoit OK, so it’s HKP, but hkp has no concept of batching requests, so this chunking is an internal gpg optimisation… yes?
@andrewg I guess. I wasn't the one analyzing the issue. Only providing the workaround script.