refresh-keys with keyserver prefs connects once per key and often fails

Bug #494017 reported by Thorsten Glaser
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GnuPG
Incomplete
Unknown
gnupg (Ubuntu)
Confirmed
Undecided
Unassigned
Nominated for Hardy by Thorsten Glaser

Bug Description

Binary package hint: gnupg

Affects both:
• gnupg-1.4.6-2ubuntu5 (hardy)
• gnupg2-2.0.7-1 (hardy)

When keys have “keyserver” preferences set (see many of the newer @tarent.de 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.

visibility: private → public
Revision history for this message
Daniel Leidert (dleidert-deactivatedaccount) wrote :

Can you please test this with recent gpg versions (e.g. in a CHROOT) and report back? Ideal would be logs (e.g. --verbose, --status-fd, --logger-fd, ...).

Revision history for this message
Thorsten Glaser (mirabilos) wrote :

I have a Karmic chroot I can probably use, would that be okay?

Revision history for this message
Daniel Leidert (dleidert-deactivatedaccount) wrote :

Kamic did not ship the latest versions, but IMHO this will still be better than the versions you reported your issue against.

Revision history for this message
Daniel Leidert (dleidert-deactivatedaccount) wrote :

Ok, from a first test it looks like this behaviour is still the same with current gnupg* versions.

A possible workaround is to use --keyserver-options no-honor-keyserver-url.

Revision history for this message
Thorsten Glaser (mirabilos) wrote :

Ah ok, thanks for testing, I didn’t get to it during the night.

I don’t know if that workaround is desirable, but I will keep it in mind
for when the keyserver indeed is DoS’d again.

Thanks for reporting to upstream, let’s hope for a real fix ☺

I wonder, are notations so rare that nobody has seen this before?

Kees Cook (kees)
security vulnerability: yes → no
Changed in gnupg:
status: Unknown → Incomplete
Revision history for this message
Thijs Kinkhorst (kink) wrote :

Confirmed, but upstream indicates that it's not quite trivial to fix.

Changed in gnupg (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.