FS#52234 - [gnupg] Unable to connect to keyservers for any action with 2.1.17

Attached to Project: Arch Linux
Opened by Arsalan (afzalarsalan) - Thursday, 22 December 2016, 10:42 GMT
Last edited by Gaetan Bisson (vesath) - Friday, 23 December 2016, 21:34 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

Description:
With the new update to GnuPG, I noticed that I was unable to retrieve, search, or send keys, with all three actions resulting in a "no keyserver" error. Reinitialized both my home directory and pacman .gnupg directories to ensure this problem wasn't due to a configuration change but no dice. Rolling back to GnuPG 2.1.16 immediately fixed the issue and I expect this is due to the new resolver code and some weird interaction with Arch in particular. Even tried the --standard-resolver option inside dirmngr.conf as mentioned in the changelog but I just ended up getting "Unresolved Host".

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
Update to GnuPG 2.1.17
Try to get a key from any keyserver or pacman-key --refresh-keys
This task depends upon

Closed by  Gaetan Bisson (vesath)
Friday, 23 December 2016, 21:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  gnupg-2.1.17-3 in [testing]
Comment by brent saner (sanerb) - Thursday, 22 December 2016, 15:31 GMT
Confirming:

[root@archdev ~]# ps auxf|egrep -E '(gpg|dirmngr)' | grep -v grep
[root@archdev ~]# rm -rf .gnupg
[root@archdev ~]# echo $GNUPGHOME

[root@archdev ~]# gpg --debug 1024 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys 9741E8AC
gpg: Note: no default option file '/root/.gnupg/gpg.conf'
gpg: enabled debug flags: ipc
gpg: directory '/root/.gnupg' created
gpg: new configuration file '/root/.gnupg/dirmngr.conf' created
gpg: new configuration file '/root/.gnupg/gpg.conf' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: DBG: chan_3 <- # Home: /root/.gnupg
gpg: DBG: chan_3 <- # Config: /root/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.17 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.17
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- 9741E8AC
gpg: DBG: chan_3 <- ERR 219 Server indicated a failure <Unspecified source>
gpg: error searching keyserver: Server indicated a failure
gpg: keyserver search failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: secmem usage: 0/32768 bytes in 0 blocks
Comment by brent saner (sanerb) - Thursday, 22 December 2016, 15:50 GMT
bug filed upstream:

https://bugs.gnupg.org/gnupg/issue2889

maintainer, is it possible to do a rollback operation? this not only breaks core GPG functionality, but also breaks core Arch functionality.
Comment by Doug Newgard (Scimmia) - Thursday, 22 December 2016, 16:21 GMT
I don't see how core Arch functionality requires remote operations. Yes, this is a huge problem, but it doesn't really affect the way Arch uses it.
Comment by brent saner (sanerb) - Thursday, 22 December 2016, 16:25 GMT
pacman-key, doug.
Comment by Doug Newgard (Scimmia) - Thursday, 22 December 2016, 16:36 GMT
Which is not required outside the initial setup and does not require access to remote keyservers for that.
Comment by brent saner (sanerb) - Thursday, 22 December 2016, 16:43 GMT
considering that installation is a core part of any operating system, and breaking that therefore breaks core functionality, i may disagree with you.

i didn't come here to bicker over semantics nor prioritization of what does and does not constitute core functionality, i came to confirm a very serious bug and report that it is reported upstream.
Comment by Gaetan Bisson (vesath) - Thursday, 22 December 2016, 18:17 GMT
I'm hoping upstream will fix this issue today or tomorrow. If not, I'll push 1:2.1.16.
Comment by Doug Newgard (Scimmia) - Thursday, 22 December 2016, 18:44 GMT
Tried building with --disable-libdns to revert to previous behavior, but build fails. Not enough ifdefs, it seems.
Comment by Mateusz Paluszkiewicz (TheAifam5) - Thursday, 22 December 2016, 19:45 GMT
Tests on production ^^ So, actually my server stuck because of this package :( I hoping that upstream will fix this today
Comment by Gaetan Bisson (vesath) - Friday, 23 December 2016, 07:22 GMT
So I came up with a fix that does two things:
- fallback on the old, standard resolver code
- if no SRV record is found, use CNAME (as expected but some weird error code apparently broke this)

Please sign off on 2.1.17-2 in [testing].
Comment by brent saner (sanerb) - Friday, 23 December 2016, 09:39 GMT
presented patch to upstream. i think fallback may be a bit more clean than a runtime or build configuration option, but it's of course up to them.
Comment by brent saner (sanerb) - Friday, 23 December 2016, 09:57 GMT
(also, confirming fix in 2.1.17-2's libdns.patch. works for me on a fresh barebones VM with no pre-existing .gnupg/dirmngr instance/gpg-agent instance etc.)
Comment by Doug Newgard (Scimmia) - Friday, 23 December 2016, 15:12 GMT
Upstream patch, nearly identical: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blobdiff;f=dirmngr/dns-stuff.c;h=a31b0731c930ffa80a626481a705fd096f4f7648;hp=491fccefda17178bfde1162a2dfee37f86389049;hb=d26c51825e2255fe58305cbc1cd74fa43f80d93e;hpb=1909e994cb87d6c6866a465f0c20a456d4df46cc

Loading...