FS#52354 - [gnupg] 2.1.17-3 broken DNS

Attached to Project: Arch Linux
Opened by Noel Kuntze (thermi) - Tuesday, 03 January 2017, 16:47 GMT
Last edited by Gaetan Bisson (vesath) - Thursday, 19 January 2017, 23:32 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Sébastien Luttringer (seblu)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

The gnupg package in version 2.1.17-3 has broken DNS resolving and is unable to use keyservers.
Downgrading to 2.1.16-1 makes it work. I can not test the 2.1.17-{1,2}, because I do not have
those packages.

Additional info:
* package 2.1.17-3
* config and/or log files etc.

Steps to reproduce:

1. Install 2.1.17-1
2. Try to refresh, upload, download or search keys
3. Watch it fail
Output:

LANG=C gpg --verbose --verbose --search-keys robert@alsdorff.de
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

   gpg.conf (9 KiB)
   gpg-agent.conf (0.3 KiB)
   dirmngr.conf (0.2 KiB)
This task depends upon

Closed by  Gaetan Bisson (vesath)
Thursday, 19 January 2017, 23:32 GMT
Reason for closing:  Fixed
Additional comments about closing:  gnupg- 2.1.17-4 in [testing]
Comment by Noel Kuntze (thermi) - Tuesday, 03 January 2017, 16:49 GMT
I forgot to mention why I think this is a DNS problem:
The DNS resolution works and gpg gets a reply with the requested A/AAAA/SRV record, however it reports those as being not known and there's a patch in the 2.1.17-3 package, that patches some stuff regarding libdns, it seems. So I guess this patch could have broken it.
Comment by Doug Newgard (Scimmia) - Tuesday, 03 January 2017, 17:02 GMT
Did you kill dirmngr between versions?
Comment by Noel Kuntze (thermi) - Tuesday, 03 January 2017, 17:03 GMT
Yes, I did. I also terminated it between tests.
Comment by Pablo Pedrotti (melcor) - Tuesday, 03 January 2017, 17:31 GMT
I also have this issue. It works when I enter the IP address of the server, but it doesn't when I use its domain.

Example:
$ gpg --recv-keys --keyserver hkp://18.9.60.141 1EB2638FF56C0C53 works
$ gpg --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53 does not work
Comment by Doug Newgard (Scimmia) - Tuesday, 03 January 2017, 18:03 GMT
What's with the first URI ending with a "."?
Comment by Noel Kuntze (thermi) - Tuesday, 03 January 2017, 18:06 GMT
That does not matter. 2.1.17-3 does not work with all keyservers in dirmngr.conf commented out (it should default to hkps://hkps.pool.sks-keyservers.net, as the man page for dirmngr says) or not and in any combination.
Comment by Gaetan Bisson (vesath) - Wednesday, 04 January 2017, 00:04 GMT
It works for me:

$ gpg --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53
gpg: key 1EB2638FF56C0C53: public key "Dave Reisner <d@falconindy.com>" imported
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 16 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1 valid: 16 signed: 8 trust: 16-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2018-02-03
gpg: Total number processed: 1
gpg: imported: 1

Please try running:

$ gpg --homedir /tmp --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53

If this works, the issue is with your configuration files, then you can do a binary search to find the offending option and report it upstream. Cheers.
Comment by Noel Kuntze (thermi) - Wednesday, 04 January 2017, 00:09 GMT
Does not work.

LANG=C gpg --homedir /tmp --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53
gpg: keyserver receive failed: No keyserver available
Comment by Gaetan Bisson (vesath) - Wednesday, 04 January 2017, 01:49 GMT
Did you also try killing gpg-agent?
Comment by Noel Kuntze (thermi) - Wednesday, 04 January 2017, 02:05 GMT
Yes. I always killed and still kill gpg-agent and dirmngr before testing.
Comment by Gaetan Bisson (vesath) - Wednesday, 04 January 2017, 02:12 GMT
Well sorry but I'm out of ideas and it's hard to diagnose when I cannot reproduce this issue on my machines.
I recommend you try building the latest git snapshot of gnupg from source: if it fixes the problem I can backport the relevant commit into our package, and if not you should definitely bring this up with upstream. Cheers.
Comment by Pablo Pedrotti (melcor) - Wednesday, 04 January 2017, 04:29 GMT
I use the default configuration and it does not work. The default configuration should work fine as it used to. I can't find any configuration that would make it fail the way it does now.

I'll try to see if there is anything that may be breaking gnupg here, and report a bug upstream.

By the way, I am using systemd-networkd and systemd-resolved to configure my network connection, in case that matters.
Comment by Noel Kuntze (thermi) - Wednesday, 04 January 2017, 17:25 GMT
I found a working combination.
The source has to be patched with the patch given in commit b200e636ab20d2aa93d9f71f3789db5a04af0a56 [1],
additionally to the one that is already in the source of the package with version 2.1.17-3 (called libdns.patch there)
and gnupg has to be built with libdns.

[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b200e636ab20d2aa93d9f71f3789db5a04af0a56
Comment by Gaetan Bisson (vesath) - Wednesday, 04 January 2017, 19:03 GMT
If I build gnupg like you say I get:

$ gpg --recv-keys --keyserver hkp://pgp.mit.edu 1EB2638FF56C0C53
gpg: keyserver receive failed: Server indicated a failure

And subsequent calls return:

gpg: keyserver receive failed: No keyserver available

I'd really love to get upstream's libdns to work but somehow we're not there yet.
Comment by Noel Kuntze (thermi) - Wednesday, 04 January 2017, 19:46 GMT
I would like to start comparing DNS settings, as well as DNS requests and responses.
Attached you find the DNS query and response, as well as my resolv.conf.

EDIT: Misclicked when trying to add the attachements. They're now attached.
   resolv.conf (0.1 KiB)
   dns.pcapng (1.5 KiB)
Comment by Gaetan Bisson (vesath) - Wednesday, 04 January 2017, 23:26 GMT
It works for me with any nameserver: unbound running on localhost, my LAN's nameserver, and Google's 8.8.8.8.

What's weird however is that capturing packets (see attached) I can see the SRV record being asked, none being found, but no query for the A/AAAA record is ever made. I'm not sure where the IP address of pgp.mit.edu could be hardcoded on my system...

(Edit: Just to be clear, all this is using gnupg-2.1.17-3 from [core].)
   query.pcapng (1.2 KiB)
Comment by Noel Kuntze (thermi) - Wednesday, 04 January 2017, 23:36 GMT
Make sure you killed dirmngr and gpg-agent before testing or trying the newly compiled version and make sure your PKGBUILD looks like the attached one.
To avoid stupid errors, the two patches and the install file are attached as well.

I think dirmngr caches DNS responses or something else does. I observed the same thing when testing the failure in I'M experiencing with -3, when I don't kill gpg-agent
and dirmngr beforehand.

Do you mind making a capture with my PKGBUILD an the new patch?
Btw: I'm having the failure on -3 on a different installation on my Laptop as well and that also happened in another network at 33c3.
   PKGBUILD (2.1 KiB)
   libdns.patch (1.9 KiB)
   dns-stuff.patch (1.5 KiB)
   install (0.2 KiB)
Comment by Gaetan Bisson (vesath) - Friday, 06 January 2017, 07:04 GMT
No worries: I kill dirmngr and gpg-agent properly before each test.

Here's what I get with your proposed PKGBUILD. I'm not sure why the broadcast: I had set my nameserver to 8.8.8.8 in resolv.conf.
   libdns-and-both-patches.pacpng (0.3 KiB)
Comment by Gaetan Bisson (vesath) - Friday, 06 January 2017, 07:17 GMT
I'm not saying it's expected, but libdns is new code so it's bound to have a few issues. What I find more surprising is that you're having issue with --disable-libdns as implemented in gnupg-2.1.17-3 (currently in [core]) because this uses exactly the code that 2.1.16 used. And what's even more strange is that your packet capture reveals that gnupg actually receives DNS replies containing the IP address of pgp.mit.edu so there should really be no issue. Could you perhaps try disabling IPv6 on your machine (if you have it enabled) to see if the lack of AAAA records could be an issue for you? That's the only idea I have right now...
Comment by Gaetan Bisson (vesath) - Friday, 06 January 2017, 07:18 GMT
Also, you don't have nscd running, do you?
Comment by Noel Kuntze (thermi) - Friday, 06 January 2017, 15:03 GMT
I don't think the UDP broadcast has anything to do with gpg2 or DNS resolution in any case. The packets don't contain any string or any data structure that is long enough to be a DNS name. They're also no DNS packets.

I disabled IPv6 on my interface and there's still no working keyserver interaction. So I think that it's independent of IPv6. (I have working IPv6 and the package that my PKGBUILD produces works fine with that).

No, I don't use nscd. It's also not running.
What's your /etc/nsswitch.conf? Mine's attached.
   nsswitch.conf (0.2 KiB)
Comment by Noel Kuntze (thermi) - Monday, 09 January 2017, 23:13 GMT
I found a source of problems with dirmngr and nsswitch.conf.
If nsswitch.conf is slighly malconfigured for hosts resolution, like the following[1], keyserver interaction does not work. Removing the ! from [!UNAVAIL=return] makes it work.
However, it does not fix the problem with gnupg 2.1.17-3.
the hosts line was taken from the avahi wiki article[2].
I would really like to see your nsswitch.conf file, Gaetan.

[1] Failing nsswitch.conf hosts line: `hosts: files mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname`
[2] https://wiki.archlinux.org/index.php/avahi
Comment by Gaetan Bisson (vesath) - Monday, 09 January 2017, 23:59 GMT
Noel: I'm using the default nsswitch.conf from the filesystem package:

# Begin /etc/nsswitch.conf

passwd: compat mymachines systemd
group: compat mymachines systemd
shadow: compat

publickey: files

hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

# End /etc/nsswitch.conf
Comment by Gaetan Bisson (vesath) - Tuesday, 10 January 2017, 00:01 GMT
If it turns out we need to remove that exclamation mark from nsswitch.conf to have gnupg's libdns work properly we'd need to be very careful and take this up with the filesystem maintainer to make sure we do not break anything else in the distro. I'm hoping there is a gnupg-specific fix for those issues.
Comment by Noel Kuntze (thermi) - Tuesday, 10 January 2017, 20:55 GMT
Gaetan: Do you mind testing if gnupg's libdns works when you remove the exclamation mark?
Comment by Gaetan Bisson (vesath) - Saturday, 14 January 2017, 20:48 GMT
Yes indeed, Noel, it works. I'll add the filesystem maintainer to this discussion.
Comment by Gaetan Bisson (vesath) - Saturday, 14 January 2017, 20:52 GMT
Hi Sebastien. Just to summarize the discussion: GnuPG's new libdns code fails on vanilla Arch installations. Upstream sees nothing wrong with it. We found out that changing "[!UNAVAIL=return]" to "[UNAVAIL=return]" (removing the bang) in /etc/nsswitch.conf allows that code to work. Would that be a welcome change to the filesystem package? Cheers.
Comment by Gaetan Bisson (vesath) - Thursday, 19 January 2017, 09:20 GMT
So I had a look at gnupg's libdns code and couldn't find where it handles the negation (the bang in !UNAVAIL). Turns out: nowhere. That might very weel be the issue. Until upstream comes up with a way to properly handle this, I wrote a patch that simply ignores such statements.

Please test gnupg-2.1.17-4 from [testing]
Comment by Noel Kuntze (thermi) - Thursday, 19 January 2017, 14:28 GMT
I built the package with the patch in gnupg-2.1.17-4 from [testing] with the nsswitch.conf that previously failed and it works now.

Gaetan: Do you mind bringing that upstream and getting a discussion started to get it included there?
Comment by Gaetan Bisson (vesath) - Thursday, 19 January 2017, 17:07 GMT
I did that already: https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032480.html
Comment by Gabriel Souza Franco (gbs) - Thursday, 19 January 2017, 20:35 GMT
I tried gnupg-2.1.17-4 from [testing] and it still fails for me with the default nsswitch.conf:

$ gpg --recv-keys 0x20D04E5A713660A7
gpg: keyserver receive failed: Server indicated a failure
$ gpg --recv-keys 0x20D04E5A713660A7
gpg: keyserver receive failed: No keyserver available
Comment by Gaetan Bisson (vesath) - Thursday, 19 January 2017, 23:32 GMT
Gabriel: Then your issue is not that which Noel reported in this bug. Please create a new bug report and provide sufficient information for others to reproduce and/or fix it.

Loading...