Mon, Apr 25
Was fixed in 2.3.5
Mar 21 2022
Actually this is pretty obvious; we better ignore such misbehaving servers.
Mar 16 2022
Dec 6 2021
Hi guys, I just tested the git version (426d82fcf1c133bfc1d5c931109d71db3f3815a9) and it works well thank you.
Fixed in 2.2.33.
Oct 15 2021
I don't know if it's same in your case, but to fix my case, I pushed a change rG48359c723206: dns: Make reading resolv.conf more robust.
I managed to create a case. Put a line:
BTW, in your screen shot (log is preferred here), it shows 1c00, that must be actually written as AAAA (0x1c). In the bug T3803, we saw byte sequence like that, additional 00 was added then resulted malformed DNS packet.
Oct 14 2021
dots are not allowed in hostnames.
OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com
Ah, other possible case is .. in hostname.
It's hard to investigate your problem, with no information of host for the query.
I mean, there is no case to replicate (for us).
Oct 13 2021
Aug 13 2021
Dec 22 2020
Granted I'm not familiar with the functions and it may not be applicable, but the DNS resolver functions in the GNU C Library have semi-recently gained parameters (RES_USE_DNSSEC) to check for DNSSEC validation IIRC. Recent versions of glibc also don't trust the 'ad' bit unless an indication of its trustworthiness is set in /etc/resolv.conf, say if using a local validating resolver, so one can be sure that it's trustworthy. It also appears musl libc may support this.
Nov 26 2020
Or it might be related issue of name server access like in T3168: dirmngr: gpg: keyserver receive failed: No keyserver available.
This must be an issue of SRV record retrieval.
Jul 1 2020
DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.
Jun 30 2020
The same concern has been reported at https://bugs.debian.org/964033 -- if dirmngr is not going to follow the specification, it should at least document (and maybe warn?) about how it is divergent.
Oct 25 2019
Aug 22 2019
Fixed in master.
This part of code is questionable. It always comes fp!=NULL, so the part should be removed.
If fp==NULL, use of tmpfile is quite questionable because a user can't know where the trace output goes.
I'm going to remove that part.
Aug 10 2019
WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:
Aug 6 2019
DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.
Jul 11 2019
Is this really necessary to duplicate functionality that already is provided by Web Key Directory?
Jul 10 2019
I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.
Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.
Jul 3 2019
I asked you to carry this to a mailing list and not re-open this task.
May 23 2019
Are you not reading what I am saying to you?? Once again, your explanation is INVALID because that would mean that gnupg would be BROKEN, because it would be a NON-COMPLIANT http client according to the RFC I quoted.
I explained why the keyserver access requires access to the DNS. If that is not possible the keyserver code will not work. If you don't allow DNS to work you either have to use Tor (which we use to also tunnel DNS requests) or get your keys from elsewhere. Also note that the keyserver network is current several broken and under DoS and thus it is unlikely that it can be operated in the future.
May 17 2019
Apr 1 2019
HTTP/1.1 spec, RFC 7230, Section 5.4, paragraph 2:
Please be so kind and point me to the specs stating that you should put the IP address into Host:
It's up to GPG to send the Host header that shows the user's intent.
So in short you want:
- Allow to specify a keyserver by IP without any DNS lookups.
- When connecting via IP use the IP address for Host:.