I've tried latest master and it no longer hangs for me.

Thanks. Changing the status to not-released as this is fixed.

Indeed, I can reproduce this.

PS: Hi flokli :)

And failing with IPv6 nameserver.

Here's running normally (not in a container) using IPv4 nameserver.

Arch Linux. The PID was due to running in a container.

Hi,

I am using systemd-resolved. It is listening on localhost UDP.

What OS are you using? It looks like A Linux distro but the process id 10 is a
little bit unlikely.

Please add

verbose
debug ipc,dns
log-file /foo/bar/dirmngr.log

to dirmngr.conf, kill dirmngr (gpgconf --kill dirmngr), and retry. Show us the
log then.

4ce4f2f683a17be3ddb93729f3f25014a97934ad allows make check to complete without
the other workaround. So it works as advertised! Thanks, Niibe and Justus.

Error output:

dirmngr[9.5]: handler for fd 5 started
dirmngr[9.5]: connection from process 10 (1000:1000)
dirmngr[9.5]: command 'KS_GET' failed: Server indicated a failure <Unspecified
source>
gpg: keyserver receive failed: Server indicated a failure
dirmngr[9.5]: handler for fd 5 terminated

Yes, I think that would be good.

Sure: https://gist.github.com/ilovezfs/c0754cd0f5795b4830cc55cec1b0d016

Hi,

can you tell me what kind of DNS resolver is listening on localhost? Does it
support UDP? TCP?

Justs, can you please check this bug. It is related to the migration to libdns
and thus we should consider this a bug.

Justus, I mentioned several solutions on Jabber which do not affect the rule not
to modify CFLAGS.

Note that simply reverting 02eb9fc9d5863abcfed6af704e618f8cac7cc2e8 will make
our sanitizer build miscompile, likely because -fsanitize=x breaks some test.
This would be easy to fix with my approach, but Werner does not like it.

Reverted 4b57359ef3ce0b87e15889e12ef0fcd23f62dcb4.

Fixed in 4b57359ef3ce0b87e15889e12ef0fcd23f62dcb4.

Fixed in 591b6a9d879cbcabb089d89a26d3c3e0306054e1.

my resolv.conf
nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver ::1
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844

I have test with 2.1.19 it works the same

Since this is for command-ssh.c, we can't change the protocol (the client is SSH
process, which doesn't use libassuan).
Here, the purpose of the code is getting PID of peer, so, we can do something
except FreeBSD.

I think that it is fixed in: f7f806afa5083617f4aba02fc3b285b06a7d73d4

What's your /etc/resolv.conf ? Would you mind to also test with 2.1.19?

My main reasons why I don't want to consider this now are:

• That code is not written and thus will not be matured.
• It does not solve the major problem why we moved to /var/run, namely remote file systems and avoidance of possible re-mounted file systems
• The claim that /var/run/user does not exists is not valid, because that is a simple dependency for building the software or using it with non-common setups (remot, long $HOME). Thus an admin will anyway be on duty and adding a few lines to /etc/rc.local is not a bug deal.

FWIW, we may try this in 2.3 see T2987.

Werner does not think that this is a problem and does not want me to spend time
on this.

getsockname is only used to recover the paths of sockets bound by a supervisor
like systemd. So unless systemd starts doing the same trick that I propose,
there is no problem.

Sorry, I couldn't find any possible bug for PC/SC access in scdaemon. It looks
like scdaemon crashes when it tries to access card by PC/SC, and it seems that
it crashes there (I mean, in PC/SC).
I believe that this scdaemon's crash is something which is difficult to avoid in
an application.

Anyway, I fixed the issue itself by handling errors of gpg-agent for scdaemon:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=4ce4f2f683a17be3ddb93729f3f25014a97934ad

2.1.19 behaves (almost) the same:

• dirmngr does ignore /etc/hosts
• dirmngr is only resolving trough dns

SRV? _pgpkey-https._tcp.keyserver.example.com. (59)
SRV? _pgpkey-https._tcp.keyserver.example.com.localdomain. (71)
A? keyserver.example.com. (40)
A? keyserver.example.com.localdomain. (52)
AAAA? keyserver.example.com. (40)
AAAA? keyserver.example.com.localdomain. (52)
A? keyserver.example.com. (40)
A? keyserver.example.com.localdomain. (52)
AAAA? keyserver.example.com. (40)
AAAA? keyserver.example.com.localdomain. (52)

The command output changed slightly:

gpg2 --debug-level guru --search-keys example.com
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust
hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /tmp/gnupg-test
gpg: DBG: chan_3 <- # Config: /tmp/gnupg-test/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.19 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.19
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- example.com
gpg: DBG: chan_3 <- ERR 167772380 No name <Dirmngr>
gpg: error searching keyserver: No name
gpg: keyserver search failed: No name
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0

outmix=0 getlvl1=0/0 getlvl2=0/0

gpg: secmem usage: 0/32768 bytes in 0 blocks

This patch tried to fix the issue:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=f9acc7d18bb90f47dafe7e32ae92f567756d6b12

I was wrong that PIPE can be select(2)-ed on Windows. This patch changes the
code so that it uses kill(2) on UNIX and SetEvent on Windows
to break the loop.

Thomas confirmed this, with our workaround for the SNI problem removed the
problem still occurs. We have activated our workaround again to keep wks working
on testkolab.

I think gniibe may have posted a related patch to gnupg-devel some time ago not
to abort on non fatal GNUTLS alerts but I don't think it was applied.

This issue does not have high priority for me so I downgraded to minor bug but
it's still an issue.

With this patch the log message is different (No such file or directory). Hang
still happens.

2017-03-03 10:21:06 scdaemon[8604] DBG: enter: apdu_get_status: slot=0 hang=0
2017-03-03 10:21:06 scdaemon[8604] DBG: leave: apdu_get_status => sw=0x0 status=7
2017-03-03 10:21:06 scdaemon[8604] npth_pselect failed: No such file or
directory - waiting 1s

Version was 2.1.19 from the installer built by werner / the speedo system.

I'll try out the patch

I think that scdaemon in 2.1.18 would also crash in sandbox environment.
In 2.1.19, I modified ssh-agent emulation code to support multiple tokens.
This change assumes scdaemon returns ENODEV return code and behaves badly, if
scdaemon crashes.
In 2.1.18, the code was somewhat robust and scdaemon crash didn't cause failure.
I am currently looking into the reason why scdaemon crashes.

It seems npth_eselect is for network FDs.

How about this change?

diff --git a/scd/scdaemon.c b/scd/scdaemon.c
index f7e9f83b5..462ff1b3e 100644

• a/scd/scdaemon.c

+++ b/scd/scdaemon.c
@@ -1291,7 +1291,7 @@ handle_connections (int listen_fd)

while (npth_sigev_get_pending(&signo))
  handle_signal (signo);

#else

• ret = npth_eselect (nfd+1, &read_fdset, NULL, NULL, t, NULL, NULL);

+ ret = npth_select (nfd+1, &read_fdset, NULL, NULL, t);

saved_errno = errno;

#endif

It is selecting FD which is created by gnupg_create_pipe.

Version information, please.

I cannot replicate this on GNU/Linux with PC/SC (by disable-ccid).
Anyway, I am looking into this issue:

npth_pselect failed: Input/output error - waiting 1s

From T2833 (wk on Mar 02 2017, 07:49 PM / Roundup) I don't think the problem is resolved. Yes it works now with
gnutls and ntbtls because we fixed / changed it on our side. There were no
changes to the GnuTLS code regarding alerts afaik.

Thomas: I've assigned this now to "no-selection" if possible I would have
assigned it to you. Can you come up with a test / demo that shows that this
problem still exists. Something werner could test against?

Glenn: I'm not exactly sure why your scenario exposed this issue. I suspect
that it has something to do with you have never used this key for encryption
prior to the verification, but it would require more investigation to confirm.

The page now links to the Wiki which makes sure that things are up to date.

Neal: Do you have an answer for him?

Fixed with commit b1f48da for 2.1.20

Tried with ntbtls and gnutls - both work fine now. Given the work we did with
recent release I will close this bug now.

Did you changed --default-cache-ttl or --max-cache-ttl to zero or another small
value? The multifile feature requires that the passphrase cache has been enabled.

I think it is easier to enforce this than to handle bug reports due to
export/import and whatever problems.

We should better fix that by adding a new API to libassuan so that we have that
code only once.

Thanks for the report.

Shall I then thake this bug?

That implicit local is for backward compatibility and to avoid network lookups
as much as possible (privacy leak). "clear" is required because auto-key-locate
is cumulative.

I doubt that this is Windows only. On Linux we use our own driver but on
Windows we have to resort to PC/SC. My educated guess is that we are in some
blocking system call which is not npth_unprotected.

Fixed in 0c4d0620d327e8a2069532a5519afefe867a47d6.

So I went over the code that does --locate-key. There, the available methods
are ordered, and if 'local' is not given, it is explicitly done first, unless
'nodefault' is given. This is one of the parts of GnuPG that I'm really afraid
to change ;)

I have to refine my statement. We store the 'ultimateley trusted flag in the
trustdb and thus we require a trustdb when creating a new key. That is so that
we know the key has been created by us and is not an imported key.
Thus for most commands the trustdb should not be created but for key generation
it is better to safe that ultimately trusted flag in the trustdb.