I thoroughly tested this again with the released versions. Works very nicely, including the timeout.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 3 2018
May 2 2018
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!
Apr 30 2018
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.
Apr 26 2018
Apr 25 2018
T2984 might also be related as the fetches are ldap.
Apr 24 2018
Apr 23 2018
See also T2448
Apr 20 2018
Looks ok now in my tests. I still want to test against more CA's with more CLRs (e.g. COMODO and CACert)
Apr 18 2018
Thanks for looking into this issue :-)
Apr 17 2018
An option to ignore SRV records would also be good for debugging. Thus I raised the priority and truned this into a feature request.
Apr 16 2018
Did that help any?
Apr 13 2018
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).
Apr 12 2018
So I used a debugger to see if I could garner any additional info. Here's the log:
Apr 11 2018
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.
Apr 10 2018
dirmngr -v --debug ipc,dns,network --log-file - --server --debug-wait 3
--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?
Apr 9 2018
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.
Mar 27 2018
Thank you for your answer ! :)
You can do a
Mar 7 2018
Feb 28 2018
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:
- there are DNS queries for proxy records A & AAAA (ipv4 & ipv6 - both regardless of --disable-ipv6)
- DNS reply returns correct IP address in A record
- there are no outgoing connections to proxy IP address
$ gpg-error --desc GPG_ERR_WRONG_NAME 313 = (0, 313) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_WRONG_NAME) = (Unspecified source, Unknown error code)
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
An additional note: It is harder than with gpg-2.0 to get more details about a failed attempt to receive pubkey material. The keyserver options cannot be called from gpg direclty, but have to be given to dirmngr. I don't have a solution this, it is just an observation.
The stripped down log is
Feb 27 2018
@werner Problem persists (same results with disabling ipv4 or ipv6
Feb 23 2018
Feb 22 2018
Will go into 2.2.6
Feb 21 2018
hm, i think this is the file:
Feb 1 2018
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.
Jan 31 2018
Jan 24 2018
Jan 17 2018
Indeed with debug dns I can see that what takes so long is the resolve_dns_name. After the debug output prints that line the key comes nearly instant.
I can't replicate it here. With my key it takes
real 0m0.346s
user 0m0.080s
sys 0m0.004s
and for your key it takes a few 10ms longer (more hops). Is one of your DNS responder failing? Can you please run dirmngr with --debug dns ?
Jan 15 2018
I have exactly the same problem on my Windows 10 machine. I am using bitdefender as virus scanner, but it doesn't work no matter if it is active or not. Windows is fully updated and I am using gpg4win 3.0.3.
Jan 10 2018
I'm using gnupg 2.2.4 and this problem repros for me, and it impacts downstream things like pacman-key (Arch Linux) quite insidiously, which fails with an misleading error message that would not point a regular user to this line of investigation.
Dec 12 2017
Well the problem is both TCP and UDP. Somehow dirmngr tries to open a listening socket. I think that may be some feature probing in the DNS resolver. Because if the Firewall access is denied I don't see any feature loss.
This is very likely dirmngr's DNS resolver which uses UDP by default. Fixies: a) use Tor. b) We add an option to use only TCP queries.
Dec 11 2017
Dec 6 2017
I experience this same behavior, standard shell. Both with admin, windows live based account and local, non-admin account.
Nov 29 2017
For reference here is @mcgrof's dump in a directly readable format:
00:29:33.472844 IP 192.168.4.7.10218 > 192.168.4.1.domain: 53039+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65) 00:29:33.879268 IP 192.168.4.1.domain > 192.168.4.7.10218: 53039 FormErr 0/0/0 (65) 00:29:33.880719 IP 192.168.4.7.10218 > 192.168.4.1.domain: 51133+ Type0 (Class 8448)? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (66) 00:29:33.902115 IP 192.168.4.1.domain > 192.168.4.7.10218: 51133 FormErr 0/0/0 (65)
Nov 21 2017
Unconditionally retrying without SRV lookup is not a good idea. SRV record are there for a reason. What we could do is an option to skip SRV record lookups.
Nov 19 2017
You know... I think connman and DNS have something to do with this. Connman does some weird DNS thing. And it auto-generates /etc/resolv.conf to use localhost as the DNS server.
Nov 17 2017
Okay, I took your suggestion but also improved the documentation. Fixed in 2.2
Oh that is not good. A passed arg should not be closed by the called fucntion unless that fucntion is documented as gaining ownership of it. Let me check.
Nov 15 2017
This has been fixed a while ago my having dirmngr print a hint on the possible problem. gpg will then print a warning about a problem with the Tor configuration and with --verbose print the hint on solving this as well.
Nov 13 2017
Indeed bug in Kleo, it was always 0 in kleo. (likely created during Qt5 port) fixed with: https://commits.kde.org/kleopatra/0d53416cfbe6d8fa087887c428cdfffb13514a7d
Nov 7 2017
So maybe there is also a display problem, as I saw 0:00 in Kleo. I have to recheck.
The default for the timeout are 100 seconds. I will chnage that to 15 seconds which is the same what we use for keyservers.
Oct 26 2017
Oct 24 2017
Oct 22 2017
Can you please try again with the standard shell (and not the power shell)?
Oct 20 2017
Oct 12 2017
Hello Werner and other participants,
Oct 9 2017
The question is how to detect whether v4 or v6 is supported. Most systems support both versions but that does not mean that they can actually be used (i.e. due to improper setup or no connectivity). Even the "address family" not supported can be due to a missing kernel module and thus be a transient error message.
I agree with @kristianf that dirmngr should be more clever about this sort of failure. The error message could be clearer at least, but the right response is really to skip all IPv4 addresses if the machine has no IPv4 stack, and to skip all IPv6 addresses if the machine has no IPv6 stack.
The workaround I've found is to put:
Sep 24 2017
Sep 22 2017
Thanks, that is interesting info, I need to look into that.
I spoke with the author of onionbalance, and they said:
Sep 21 2017
I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.