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.

Hi Werner,
I have performed some experiments on the issue I have and the following are the results:

@gniibe Thank you very much!
I've tested the change on Windows 7 and Windows 10 and the Firewall warning is indeed gone with this.

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

I will try to figure out what exactly triggers the firewall. This should really be fixed as it leads to a bad "first contact" with Gpg4win, especially as we do more locate-keys nowadays so the question pops up randomly for the user.

And 2.2 branch.

Fixed in master.

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.

@tinkerwolf This is weird... I've reinstalled my PC from scratch with an initial account set as local, and was able to set up GPG4Win perfectly fine for the first time on my PC (as I did in the VM). So, set up a VM with an initial account set up from an online account. GPG4Win started up fine... I am now really confused!! Somewhere within the getting set up with an online account, something has to be happening that interferes with dirmngr..
Will investigate further.

@RAmbidge are you able to further test this by using a VM with a MS account? I don't have the means right now, or I'd do it myself.

That actually makes sense, because it works fine on my laptop, where it's been a local account from the start, but it's broken on my desktop where it was originally a MS account, but is now local.

I'm having the same issue. I read somewhere that it's likely caused by using an online Windows account to login with. So I converted to local log in. Issue persists. As a test, I've just set up a VM with a local account set up at install, and GPG4Win works perfectly fine. So I'm guessing that there may be an issue which stays in the files system caused by online account users. I'm not a programmer and have no idea how or where to look to see what's causing it and how to fix it though.

Hi Werner,
The issue is the following:
I have 2 certificates in the trusted-certificates folder that is searched by gpgsm (C:\ProgramData\Gnu\etc\gnupg\trusted-certs) which I want to trust. When dirmngr starts, it reads the Windows trusted certifcate store (certlm.msc for both system and user - I don't know the path / location of the windows certificates folder outside certlm) and builds the list of certificates to use. Once this list is read and if any duplicates are found in the trusted-certificate folder, it ignores them - they are already present.

I do not fully understand your problem. Can you please explain it with an example and also state the full file names of the mentioned folders?

This is resolved in my opinion. I've tested with some larger CRL's and it worked on Windows.

I thoroughly tested this again with the released versions. Works very nicely, including the timeout.

Confirmed. it is also not Windows specific.

A strangeness I see is when I am searching for "zitis" on x500.bund.de I get the same key over and over again (until the list is truncated). I'm not sure if the response from the server is wrong or if we have a bug there. If I search for "Telekom" for example I get 10 different certificates, so it works there.

I felt confident enough to push a fix for the console window. The code was obvious and the fix, too.

Yes! Works nicely. I tested with unreachable and invalid servers, and with multiple queries against x500.bund.de and ca.intevation.de all is fine!

The hang appears random. It sometimes works 4 out of 5 times.

With latest gpg-error and latest gnupg It still hangs for me after printing the certificate.

T2984 might also be related as the fetches are ldap.

See also T2448

Looks ok now in my tests. I still want to test against more CA's with more CLRs (e.g. COMODO and CACert)

Thanks for looking into this issue :-)

An option to ignore SRV records would also be good for debugging. Thus I raised the priority and truned this into a feature request.

Did that help any?

Werner it would be great if you could look into this. This is currently my most annoying 2.1. regression. Especially with auto-key-locate it is unintuitive when the Firewall question pops up and appears to come out of nowhere (e.g. adding recipients in GpgOL or in Kleopatra).

So I used a debugger to see if I could garner any additional info. Here's the log:

The following post assumes that we want gpg --search to try to search; meaning that we don't want gpg to exit immediately because of the dead marks, without having sent a single network request to anyone.
The post is a bit long; sorry about that.

--debug-wait 3

@werner here's the only output I get:

Please kill all existing dirmngr instances and don't run any programs which will trigger it to be started (e.g. Kleopatra). Then run in a _standard_ shell (cmd.exe):

I, too, have this problem. I have Windows 10 Pro 64-bit with BitDefender Total Security. My first reaction when this wasn't working was to disable all functions on BitDefender. That didn't help, so I ran dirmngr as admin in cmd (I despise PowerShell) without any luck. I created a non-admin user and ran it in there, again without luck. I've come up dry. No logs, no output, and no answers. Is there anything shy of downgrading dirmngr that will make this work? Has there been any progress as to figuring this out?

That slipped my attention due to the missing gpg22 tag I should have added. Sorry.

Is there any ETA for when this might get fixed? We are having the same issue with our keyserver since it's behind a cname.

Thank you for your answer ! :)

You can do a

That will be the IP of proxy.x.com - the log shows that it finds that. But the log also shows that it can't find the address for the other names. "No Name" is EAI_NONAME.

I did some digging with Wireshark:

1. there are DNS queries for proxy records A & AAAA (ipv4 & ipv6 - both regardless of --disable-ipv6)
2. DNS reply returns correct IP address in A record
3. there are no outgoing connections to proxy IP address

Note that "Wrong name" severely misses information about that it is connection related in any way. :)
Just adding "Connection problem: TLS: " would already help a lot.

Well, if your proxy inhibits GnuPG to retrieve information about the keyservers, GnuPG can't do anything about it.

Debugging network problems is always hard and applications should not include tcpdump facilities. Right, I consider TLS network failures identical to layer 3 network failures because we should assume that all traffic is encrypted. Wrong certificates are also a severe network failure much like wrong voltage levels at layer one ;-).

Just to clarify:
1.I'm behind corporate network
2.Network resolves only local addresses, so this is correct: dirmngr[7416]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
3.Network address of the proxy is resolvable (I can see it's address and it responds to ping
4.Internet browser without proxy will not work
5,Internet browser with the proxy below works
6.When using gpg on this computer outside of corporate network everything works

The stripped down log is

@werner Problem persists (same results with disabling ipv4 or ipv6

Will go into 2.2.6

hm, i think this is the file:

The patch is available in our downstream bugtracker as attachment to https://bugs.gentoo.org/646194

This can easily be solved by adding two more cases to handle_send_request_error(): for GPG_ERR_EADDRNOTAVAIL (that's IPv6 disabled via procfs) and GPG_ERR_EAFNOSUPPORT (that's missing kernel support). Normally I'd submit a patch but I don't care enough to jump through all the hoops just to get two-line change in.

Originally dirmngr was designed to be a system service for the reason that CRLs are not user specific. However, the majority of systems today are used by a single user and thus we dropped that feature when integrating dirmngr into gnupg.