It's up to GPG to send the Host header that shows the user's intent.

So in short you want:

1. Allow to specify a keyserver by IP without any DNS lookups.
2. When connecting via IP use the IP address for Host:.

gpg4win 3.1.6 is released which contains this fix.

Also might I add, this used to work perfectly fine in gnupg14. It seems that somewhere along the line a regression was introduced that is causing this erroneous non-compliant behavior in the HTTP client.

Why? Your explanation is invalid because it implicates dirmngr's HTTP client as not comforming to the spec laid out by the RFC. I've quite clearly explained--and backed up with the spec itself--that when a proxy variable is configured, a client should not be doing DNS lookup of the destination hostname. Is there something about that you are not understanding?

Please show an example regarding something else than a failed access to a pool of keyservers. I explained why it can't work for pools for you.

Yes you can, and no you do not. Don't believe me? Then read the spec. At no point does the spec say that there is "nothing that can be done" when a hostname cannot be resolved when connecting through a proxy. In fact, it states precisely the opposite, describing the exact procedure a client should take when making a request through a proxy. See section 5.3, paragraph 3:

No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.

There is a solution for it:

Btw. I only noticed this now as I always had "disable-tor" in my config but recently removed it for testing.

So, the keyserver operator had thrown in a hockeypuck server in the pool, causing this.. While the keyserver remains in the exclude list until confirmation it has been resolved, that explains the behavior and it has been made clear that separate software needs to use different names in the future.

@kristianf we talked about this on Saturday evening. Would you be so kind and have a quick look at the problem with the hu server?

Hi Werner and thanks for looking into this.

According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.

I want to have this fixed for the next release so prio high.

Oops. Assignee removal was an accident. Sorry for the noise here ;-)

Just as a note: To workaround this you can also place "no-use-tor" into %APPDATA%\gnupg\dirmngr.conf (you might need to create that file) %APPDATA% expands to something like "c:\users\yourname\appdata\roaming"

In T3381#121973, @madhon wrote:

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

That process is the one i killed which is part of Asus Wi-Fi Go

In T3381#121972, @Spiker wrote:

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

On Win 10 Pro it looks like File Transfer Server.exe is running on port 9050 which could be causing the issue. See screenshots.

Apparently i had a ASUS Wi-Fi go process listening on that port (even though i thought had uninstalled it), killing the process also allows dirmngr to start

Thanks you very much for your help! I think we have it. \o/

Running with the --no-use-tor results in output ending with OK Dirmngr 2.2.11 at your service, attached is the procmon output , to clear up one thing q4master.idsoftware.com points to 127.0.0.1 in my hosts file (in addition to localhost also pointing to 127.0.0.1), but it seems the issue is with the tor check

I see some strangeness:
A TCP Connect: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050
and TCP Send: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050

Done, See attached

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.