The cause is: ! in nsswitch.conf
This was fixed (2.2 branch) by rGd4c0187dd931: libdns: Hack to skip negation term. for GnuPG in Jan 2017.
I found it was fixed in the original libdns, and this fix is merged into rG20c289606f89: libdns: Sync to upstream. to GnuPG.

GnuPG itself does that in in gnupg/g10/migrate.c. We need to fixed this.

Thank you for your feedback.

It's manually written one in Debian:
https://salsa.debian.org/debian/gnupg2/blob/debian/master/debian/gpg-check-pattern.1

I manually configure IPv6 only environment, and now (forthcoming 2.2.9), it works fine for me.
So, I move this state to Testing.

• dirmngr fix for --recursive-resolver: rG5b40338f1276: dirmngr: Fix recursive resolver mode.
  • After the release, we can ask using this mode not to use nameserver in /etc/resolv.con, but resolve by libdns directly
  • Possibly, these bug reports are related: T2968: gpg --search: Connection closed in DNS, T3168: dirmngr: gpg: keyserver receive failed: No keyserver available, T3517: dirmngr: retry without SRV due to buggy routers

Applied to 2.2 branch.

As written in T2438:

I think that this is same issue of T2438: dirmngr fails repeatedly with "invalid argument", without kicking the host from its list.
Merging.

For the problem in the last comment, it was fixed in T2928: stop fetching PTR records entirely.
For the original issue, it looks that EINVAL is returned by the system call of connect(2).
That's quite strange, but, it was possible for IPv6.

Good. I don't think there is any reason to select the ephemeral port in user space (by default).
So, I disabled the feature for all OSes.

I found dirmngr tries to bind some random port. It might be the cause.

Fixed in repo (master and 1.8 branch).

Thanks for your report.
You are right.
Simply getting the information for "rng-type" through gcry_rndjent_get_version will hang.

And 2.2 branch.

Fixed in master.

It's in 2.2.4 and 1.4.23.
Closing.

I'll fix for the non-FQDN case.

I think that I identified the issue. This is the libdns (dirmngr/dns.c) problem when hostname is not FQDN.
If you change it to FQDN, you can see that it tries to search adding the domain name.

For issues/19, it is also reported in T3374: gpg recv-keys fail if first dns server end up with "Connection refused".
This is fixed in master now.
I'm not sure if original reporter's problem is issues/19 or not.

Fixed in master.

It is indirectly reported at the upstream: https://github.com/wahern/dns/issues/19

I tested on Debian with local dnsmasq. For usual setting, no problem.
If /etc/resolv.conf has nameserver 127.0.0.1 and the service by dnsmasq somehow stops, and we have another nameserver nameserver somewhere-not-local the issues/19 matters.

Informed Debian security team about our change of libgcrypt.

Change done and pushed already.

Pushed fixes to the repository at 16:00+0900 (09:00+0200). It's 0700Z.

In master, it's

commit 9010d1576e278a4274ad3f4aa15776c28f6ba965
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   Wed Jun 13 15:28:58 2018 +0900

Yes, closing.

Apparently, the check of sem_init function was not done (in config.log).
Could you please make sure to update npth/configure by npth/autogen.sh?

Could you please put the config.log of npth with the patch?
The intention of change is: we need to link -lpthread and -lrt

I realized that the test case is already there.
I'm not sure the reason why make check for npth works well on HP-UX (before the my patch). It uses npth_attr_init (hence, pthread_attr_init) in tests/t-thread.c.
Perhaps, libtool is clever enough to detect -lpthread into src/libnpth.la (dependency_libs), I suppose.