I'm thinking of how to move this forward.
The problem is that we (the developers) can't reproduce this at all and the debug output does not show anything.

Has anybody discovered a fix for this issue? I'm running Win 10 Pro with Gpg4win v3.1.5. Dirmngr is still not executing and just hangs.

So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

If you specify a pool of keyservers dirmngr selects a keyserver on its won from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

Will go into 2.1.12 to be released next week.

Thanks.

I can reproduce it if I enter your or an unknown IP address.

Mmh. It still makes a bit sense to me as I think it will be faster. But of course for memory mapped files the OS might decide.

The dirmngr may at any time open a file in that directory and thus there is no reliable way to remove the home directory when any gpg tool is running. Daemons need to be stopped before a directory can be deleted. So I think this is a non-issue and brought to the table only because we have that kludge of detecting a n unlinked directory on Unix. But even on Unix this is not possible to get rid of the home directory, for example if you want to umount it.

Sorry, it didn't made it into 2.2.11.

No more complaints thus time to close.

Fixed in master and 2.2.

It actually tries several servers but we need to set a limit because we need to cope with longer timeouts. Do you suggest to toggle between v4 and v6 addresses? That is if a v6 address fails, first try the next v4 address and it that fails, another v6 address, etc.

Oh, that is really old code dating back to dirmngr-1. There is only one user I will see whether I can replace it with the generic parser we have in http.c

If I understand the code correctly the mapping is done to let the system optimize the memory management so that the full contents of the file are not kept in memory, or is there a different reason?

Maybe related, flush also does not work on Windows:

iirrc, that are memory mapped files.

@werner
This was an issue we talked about.

I'm also seeing the same behaviour on a freshly installed Windows 10 1809 with Gpg4win v3.1.4. Have to kill dirmngr from task manager to be able to get into Kleopatra.

I believe this would be a good improvement in user experience

Hi, Has anyone found a reason why that happens. I run into the same behavior on my Windows 10 1803 computer. I have Gpg4win version 3.1.3 freshly installed and dirmngr hangs. Thanks and best regards, Peter

We assume that this has meanwhile been fixed.

Patch 0001 applied to master.

@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?

A workaround for this until the HTTP client is fixed is to just use curl instead:

I am running into the same exact issue. It seems that dirmng is incorrectly attempting to resolve the addresses for the keyservers despite having been given an HTTP proxy to connect through.

Hi,
Can I ask if there is any update on the issue that I face?

Was anyone successful in debugging dirmngr? I'm having the same issue. The dirmngr process gets stuck, no output at all, and this causes Kleopatra to get stuck waiting for it. I can only run Kleopatra after I have killed the dirmngr process. If I understand correctly I still need this process for network-related functionality, so I would need to fix it if I want to use all functions.

I got feedback from the user that had the problem. It's fixed with 2.2.9 which contains your commit afaik.

Commit rEbd5bcd2dd19ef0b1c3d33a3a388b537ba08a4eb6

it is not due to windows but due to the use of NTBTLS. I have the same problem here... and found it: We call es_fflush to let ntbtls flush its internal buffers but libgpg-error's estream module does no propagate this explicit flush to the cookie functions of ntbtls. Thus ntbtls gets stuck most of the time. I am not sure when this regression happened but it is pretty obvious.

I have logging to a socket always enabled. That may explain why I don't see that error on Unix.

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

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.