Connecting once-per-key for keys with keyserver preference vs server violate reconnection limit
Closed, WontfixPublic


I'm hereby quoting launchpad bug #494017:

When keys have “keyserver” preferences set (see many of the newer keys,
for example), the “gpg --refresh-keys” command has a weird modus operandi:

First, it takes all of the keys with a keyserver set, and connects ONCE PER KEY to
the keyserver (and often failing due to hitting the keyserver reconnection limit,
loading it, or something), then it connects ONCE for all remaining keys to the
keyserver set in ~/.gnupg/gpg.conf (which, incidentally, is the same keyserver as
the one set on all but one of the keys with a keyserver pref set in my public key
ring). This makes key refreshing very awkward, sometimes impossible.

Please (possibly report upstream) change it so that keys with the same keyserver
string listed in their pref are merged into one request, possibly merging with the
default keyserver ifi t’s also the same.

Marking this as security vulnerability because I think that, when people run
gpg --refresh-keys (or gpg2 --refresh-keys) on an automated basis and don’t
see it failing due to a loaded keyserver, they may not receive revocation
certificates in time. If you disagree, feel free to un-flag this bug.


External Link
1.4.10, 2.0.*
dleidert set External Link to 8 2009, 6:31 PM
dleidert set Version to 1.4.10, 2.0.*.
dleidert added a subscriber: dleidert.

From my investigation the only workaround seems to be the no-honor-keyserver-url
option. What I could imagine is, to test, if the given keyserver pref of a key
is equal to the specified preferred keyserver and delay this key processing and
process it with all other keys without keyserver prefs. However this won't solve
the problem completely, as all other keys would still be processed one after the
other (which BTW sounds reasonable to me).

werner added a subscriber: werner.Dec 10 2009, 11:33 AM

That is a hard to fix problem. We don't have the infrastructure to merge
keyserver requests. Adding this to gpg will be quite some work. A tentative
plan to implement this would require a local daemon to cache requests (e.g.
enhancing dirmngr) and to rework gpg to allow for asynchronous updates.

justus claimed this task.Dec 8 2015, 11:45 AM

Now that we have a dirmngr daemon, this should be feasible. I plan to implement
it like this:

Add two flags to the KS_GET command, --enqueue and --drain-queue. --enqueue
merely enqueues the key id and returns immediately, unless --drain-queue is

This will also help us address issue #1827.

justus added a subscriber: justus.Dec 8 2015, 11:45 AM
werner added a comment.Dec 9 2015, 3:27 PM

The keyserver preferences are major privacy problem. They should not be used
and in fact they are ignored in Tor mode. Thus we should not put too much work
in fixing this wish.

justus removed justus as the assignee of this task.May 3 2017, 10:32 AM
werner closed this task as Wontfix.Dec 11 2018, 12:39 PM
werner claimed this task.
pert added a subscriber: pert.Dec 15 2019, 8:09 PM