It seems that it's related to ADNS.
I fixed error handling in the commits of 8a9341b and 6f1d812, so that correct
error from adns_synchronous will be logged.
I mean, the error message of "DNS query failed: System error w/o errno" will be
improved with correct error value.

I'm trying to understand this, but I'm not seeing it.

Here's the test i did. While recording all traffic from my machine on port 53
(the dns port), i ran:

    GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr

That interactive session looked like this:

> getinfo dnsinfo
OK - ADNS w/o Tor support
> getinfo tor
dirmngr[11713.1]: command 'GETINFO' failed: False
ERR 167772416 False <Dirmngr> - Tor mode is NOT enabled
> keyserver --clear
OK
> keyserver hkps://hkps.pool.sks-keyservers.net
OK
> keyserver --resolve hkps://hkps.pool.sks-keyservers.net
dirmngr[11713.1]: DNS query returned an error or no records: No such domain

(nxdomain)

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'bone.digitalis.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'ip-209-135-211-141.ragingwire.net'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'gpg.nebrwesleyan.edu'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'host-37-191-220-247.lynet.no'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'cryptonomicon.mit.edu'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'zimmerman.mayfirst.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'sks.srv.dumain.com'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'b4ckbone.de'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'sks.spodhuis.org'

dirmngr[11713.1]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':

'oteiza.siccegge.de'

    S # https://cryptonomicon.mit.edu:443
    OK
    > keyserver --hosttable
    S # hosttable (idx, ipv6, ipv4, dead, name, time):
    S #   0       hkps.pool.sks-keyservers.net
    S #   .   --> 8 1 5* 3 4 2 10 9 7 6
    S #   1   4   bone.digitalis.org v4=212.12.48.27
    S #   2   4   ip-209-135-211-141.ragingwire.net v4=209.135.211.141
    S #   3   4   gpg.nebrwesleyan.edu v4=192.94.109.73
    S #   4   4   host-37-191-220-247.lynet.no v4=37.191.220.247
    S #   5   4   cryptonomicon.mit.edu v4=18.9.60.141
    S #   6   4   zimmerman.mayfirst.org v4=216.66.15.2
    S #   7   4   sks.srv.dumain.com v4=85.119.82.209
    S #   8   4   b4ckbone.de v4=193.164.133.100
    S #   9   4   sks.spodhuis.org v4=94.142.242.225
    S #  10   4   oteiza.siccegge.de v4=92.43.111.21
    OK
    >

So, the SRV lookup did indeed fail, but subsequent queries succeeded.

I've attached a pcapng file of the network traffic sent and received from the
described test.

The textual version of the traffic is:

query 0x311f SRV _hkp._tcp.hkps.pool.sks-keyservers.net
query response 0x311f No such name SRV

_hkp._tcp.hkps.pool.sks-keyservers.net SOA ns2.kfwebs.net

query 0x3120 A hkps.pool.sks-keyservers.net
query response 0x3120 A hkps.pool.sks-keyservers.net A 92.43.111.21 A

94.142.242.225 A 193.164.133.100 A 85.119.82.209 A 216.66.15.2 A 18.9.60.141 A
37.191.220.247 A 192.94.109.73 A 209.135.211.141 A 212.12.48.27

query 0xbd61 PTR 27.48.12.212.in-addr.arpa
query response 0xbd61 PTR 27.48.12.212.in-addr.arpa PTR bone.digitalis.org
query 0x384a PTR 141.211.135.209.in-addr.arpa
query response 0x384a PTR 141.211.135.209.in-addr.arpa PTR

ip-209-135-211-141.ragingwire.net

query 0xb36e PTR 73.109.94.192.in-addr.arpa
query response 0xb36e PTR 73.109.94.192.in-addr.arpa PTR gpg.nebrwesleyan.edu
query 0xcac3 PTR 247.220.191.37.in-addr.arpa
query response 0xcac3 PTR 247.220.191.37.in-addr.arpa PTR

host-37-191-220-247.lynet.no

query 0xd28b PTR 141.60.9.18.in-addr.arpa
query response 0xd28b PTR 141.60.9.18.in-addr.arpa PTR cryptonomicon.mit.edu
query 0x4be9 PTR 2.15.66.216.in-addr.arpa
query response 0x4be9 PTR 2.15.66.216.in-addr.arpa CNAME

2.0-27.15.66.216.in-addr.arpa PTR zimmerman.mayfirst.org PTR zimmermann.mayfirst.org

query 0x823b PTR 209.82.119.85.in-addr.arpa
query response 0x823b PTR 209.82.119.85.in-addr.arpa PTR sks.srv.dumain.com
query 0x3b0c PTR 100.133.164.193.in-addr.arpa
query response 0x3b0c PTR 100.133.164.193.in-addr.arpa PTR b4ckbone.de
query 0x9600 PTR 225.242.142.94.in-addr.arpa
query response 0x9600 PTR 225.242.142.94.in-addr.arpa PTR sks.spodhuis.org
query 0xed36 PTR 21.111.43.92.in-addr.arpa
query response 0xed36 PTR 21.111.43.92.in-addr.arpa PTR oteiza.siccegge.de

Under GNU/Linux you can compare the strace output to see that there is a problem
even if it's quick because it is cached:

~> time strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 |wc -l
33383
strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 1.04s user 0.45s
system 104% cpu 1.433 total
wc -l 0.02s user 0.16s system 12% cpu 1.433 total

~> time strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 |wc -l
558528
strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 9.60s user 8.47s
system 106% cpu 17.022 total
wc -l 0.60s user 2.34s system 17% cpu 17.022 total

This is with my normal pubring that contains 790 public keys.

Now that gnupg v2 is using gpg-agent for all of the hard work,

It isn't. The agent merely decrypts the session key. gpg then decrypts the
actual data with the symmetric cipher.

and gpg-agent either gets locked

It isn't.

or isn't parallelized,

It is.

this does not work any more.

Can you please be more specific?

We are waiting for Plusserver or one of their sub-companies to tell us how to
proceeed.

Okay, we can then add the code to dirmngr.

The README describes that this is a one time migration and that is a Good Thing.
Anything else means the addition of additional code and surprises for 2.1 using
applications by keys suddenly appearing.

The migration code is there to help the majority of users and not to help
speical use cases.

Those who really want to create new keys with 1.4 can use the standard way of
exporting and importing secret keys.

A year later on a new computer I had to troubleshoot this problem again, and
found my own bug report. So I am including the patch this time. Please consider
including the proposed change (or some other fix) into mainstream.

D320: 895_0001-Let-other-processes-use-OpenPGP-card-over-pcscd.patch

thanks, that seems to have resolved the problem in my tests.

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

There are two http links left on the page. One (drm.info) is unfortunately
unavailable over https. The other (openit.de) seems to no longer exist, as the
company has merged with another one and is only a forward to plusserver. Probably
that simply should be changed to https://www.plusserver.com/ (and maybe the logo
as well).

It seems to be solved now but see the comment in
2f7d4c3 agent: Move inotify code to common and improve it.

Weel, required if you cange an .y file.

Bison is required.
I pushed a change which prints a note if yacc is not Bison.

I was unaware that the released version does not require it.

In that case it's no bug imo. because otherwise we would also need to work with
older autotools versions etc.

Bison is a maintainer tool and regualr builds do not require it.
I am also surprised that you can build it with a regular(?) yacc.

This is fixed in 3703a4723899d7563937b4b99f5bbe4dd8d3dfed. We will release a
minor update really soon now.

I'm attaching the lsof and strace transcript in text form so it can be read
without linebreaks

btw. reason for this report is a setup of WKS where you require most recent
modern gnupg on long time distro running servers.

John is using 2.1.14, but this bug was fixed in 2.1.15.

This is apparently just re-reported on gnupg-users:

https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056892.html

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

thank you for taking time to formulate this correctly, dkg. :)

regarding symlinks, i got the idea from reading the caff source code. after a
quick chat with the caff author, i was pointed towards that discussion:

https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029301.html

... where Werner Koch suggests symlinks as a solution.

in my opinion, the solution is sub-optimal: symlinks increases the attack
surface and adds un-necessary overhead. i would prefer an a commandline flag
(e.g. --agent-socket) or environment variable to be able to select relevant
agents...

the same applies to dirmngr, apparently - caff creates symlinks for both the
agent and dirmngr. i am not sure why, but i suspect I may have to do the same,
since I have seen stray dirmngr processes lying around in my session. a
different issue, maybe, but related, implementation-wise.

Hello,

I'm using RedHat Linux which already had a version of GnuPG installed. (2.0.14)
I'm not sure what process was used to install it. I downloaded the latest
tar-ball of GnuPG Stable 2.0.30 and installed it as per the process described in
the "HOW-TO". But when I check for the version using gpg --version, it gives me
the older version 2.0.14 instead of 2.0.30. Also , there were no errors while I
installed 2.0.30 either in compilation or installation. I'm not sure why the
--version command is still displaying the old version then.

So, regarding Qt, the issue has been acknowledged
(https://bugreports.qt.io/browse/QTBUG-56452). Using IBus as suggested in
https://bugreports.qt.io/browse/QTBUG-49438, I know have dead keys working
properly in most apps. But…

Previously, the situation was as following:

— pinentry-qt4 was working everywhere.
– pinentry-qt was not working properly for me because I wasn’t able to input
some characters.
– pinentry-gnome3 wasn’t showing up in Thunderbird/Enigmail, but worked OK in a
terminal (GETPIN).
– pinentry-gtk-2 was working properly in a terminal (GETPIN), but not in
Thunderbird/Enigmail (deciphering failed, with the right passphrase obviously).

And now:

– pinentry-qt4 doesn’t exist anymore.
– pinentry-qt is as pinentry-gtk-2 was before: works OK in a terminal (GETPIN),
but not in Thunderbird (fails to decipher). Sighs…
– pinentry-gnome3 does show up in Thunderbird/Enigmail, and works correctly. I’m
currently using this one, even if that’s not totally satisfying.
– pinentry-gtk-2 doesn’t take my dead keys into account anymore.

For the last one, honestly I don’t care, gtk2 is being phased out, and it’s
probably not an issue on pinentry side.

However, the fact pinentry-qt doesn’t work correctly in Thunderbird/Enigmail is
strange. Do you think this is an issue with pinentry-qt or these programs?

We now have a macOS box, and are building our software on it using Jenkins.

On that box, I also see the gpgtar test failing in about 14% of all runs. There
is something to be learned here.

To investigate, we need more information. What OS are you using, how did you
install 2.0.14, how did you install 2.0.30, and what exactly do you mean by
"reflecting the older version"?

Fixed in 683620c4.

from a question on the ML

gpg-connect-agent --dirmngr

GETINFO dnsinfo

OK - ADNS w/o Tor support

GETINFO tor

ERR 167772416 False <Dirmngr> - Tor mode is NOT enabled

I'm going to close this due to inactivity. Feel free to reopen this with more
information.