I have just confirmed that the upstream bug T2889 affects the current stable ebuild of app-crypt/gnupg. Please see the link for more details. Workaround until this has been fixed: add the option "standard-resolver" to dirmngr.conf, then kill all running instances of dirmngr.
That particular bug (trailing dot) is fixed in 2.1.18 that contains https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b200e636ab20d2aa93d9f71f3789db5a04af0a56 which resolves the upstream bug fixed I'd rather expect this relates to non-standard (missing "dns") resolver for hosts in /etc/nsswitch.conf
Not to raise any false alarms here, but for me this bug - or a variant of it? - still seems to apply even to 2.20.0-r1. I've been wondering why refreshing keys suddenly stopped working after recent updates on ~arch ("Address family not supported by protocol"), but with this workaround refresh works again.
(In reply to Holger Hoffstätte from comment #2) > Not to raise any false alarms here, but for me this bug - or a variant of > it? - still seems to apply even to 2.20.0-r1. I've been wondering why > refreshing keys suddenly stopped working after recent updates on ~arch > ("Address family not supported by protocol"), but with this workaround > refresh works again. Address family not supported sounds like a local IPv6 configuration issue?
(In reply to Kristian Fiskerstrand from comment #3) > (In reply to Holger Hoffstätte from comment #2) > > Not to raise any false alarms here, but for me this bug - or a variant of > > it? - still seems to apply even to 2.20.0-r1. I've been wondering why > > refreshing keys suddenly stopped working after recent updates on ~arch > > ("Address family not supported by protocol"), but with this workaround > > refresh works again. > > Address family not supported sounds like a local IPv6 configuration issue? That's what I thought. Unfortunately: - this used to work not too long ago; I ran --refresh-keys when I exported/re-imported my keyring to recover from recent gnupg breakage. - it also happens when I explicitly specify the keyserver, regardless of IPv4/v6 (e.g. the v4-only pool). - it works fine when I rebuild gnupg with --disable-libdns; tested (with removed config) as alternative to the dirmngr configuration settting mentioned above. Since everything else IPv4/v6 related works just fine here all fingers point to their homegrown resolver code.
(In reply to Holger Hoffstätte from comment #4) > - it works fine when I rebuild gnupg with --disable-libdns; tested (with > removed config) as alternative to the dirmngr configuration settting > mentioned above. Possibly related to https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=247932f367f856e7ce91528e14f0aaf838150857 and https://dev.gnupg.org/T3105
(In reply to Kristian Fiskerstrand from comment #5) > (In reply to Holger Hoffstätte from comment #4) > > > > - it works fine when I rebuild gnupg with --disable-libdns; tested (with > > removed config) as alternative to the dirmngr configuration settting > > mentioned above. > > Possibly related to > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit; > h=247932f367f856e7ce91528e14f0aaf838150857 and https://dev.gnupg.org/T3105 Very interesting! I think this may have happened after I updated to gcc7, which might explain overly zealous optimization of questionable code. I'll give that patch a try and report back.
(In reply to Holger Hoffstätte from comment #6) > Very interesting! I think this may have happened after I updated to gcc7, > which might explain overly zealous optimization of questionable code. > I'll give that patch a try and report back. Bingo! Removed the dirmngr config, verified failure, added patch to ebuild, rebuilt, --refresh-keys works again against standard keyserver pool. \o/ It's probably a good idea to include that patch everywhere.
(In reply to Holger Hoffstätte from comment #7) > (In reply to Holger Hoffstätte from comment #6) > > Very interesting! I think this may have happened after I updated to gcc7, > > which might explain overly zealous optimization of questionable code. > > I'll give that patch a try and report back. > > Bingo! Removed the dirmngr config, verified failure, added patch to ebuild, > rebuilt, --refresh-keys works again against standard keyserver pool. \o/ > It's probably a good idea to include that patch everywhere. I expect a new upstream release relatively soon (https://dev.gnupg.org/T3150) so won't backport it to 2.1.20
(In reply to Kristian Fiskerstrand from comment #8) > (In reply to Holger Hoffstätte from comment #7) > > (In reply to Holger Hoffstätte from comment #6) > > > Very interesting! I think this may have happened after I updated to gcc7, > > > which might explain overly zealous optimization of questionable code. > > > I'll give that patch a try and report back. > > > > Bingo! Removed the dirmngr config, verified failure, added patch to ebuild, > > rebuilt, --refresh-keys works again against standard keyserver pool. \o/ > > It's probably a good idea to include that patch everywhere. > > I expect a new upstream release relatively soon > (https://dev.gnupg.org/T3150) so won't backport it to 2.1.20 To avoid confusion, the patch for the actual keyring corruption _is_ included in our 2.0.21-r1 package, but the other issue will be included in the .21 release anyways
When switching from 2.1.15 to 2.1.20-r1 I also ran into this problem. The system normally runs ipv4 only. An update to 2.1.22 also didn't help. I was able to resolved the problem by loading the ipv6 kernel module.
I've filed another bug upstream: https://dev.gnupg.org/T3331
This is fixed in current versions of gnupg
