Please remove the drm.info logo and url. This is an FSFE project and (iirc)
they stopped the DRM project and thus tehre is no budget for doing even trivial
things.
They scared the voluntary sysadmins mostly away.

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

I updated the logo and link to PlusServer.

The remaining issue is the link to drm.info. I contacted the people running the
site in January, and I was told that the issue will be dealt within a few months.

Hi,

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

gnupg fixed in dd60e868d2bf649a33dc96e207ffd3b8ae4d35af.

ntbtls fixed in e582e91e47a164816ac074b9078dbed8537601dc.

libgcrypt fixed in 654024081cfa103c87bb163b117ea3568171d408.

libksba fixed in 561d03a008150c201ece22b29c97b24a1f6bf590.

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.

libassuan fixed in b26b73d04bff10852382113ae361ea5726661510.

libgpg-error fixed in 5e51b642f747547c737a7abbc37e65b0f630d188.

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.

Simple Y2038 problem. Fixed in de3838372ae3cdecbd83eea2c53c8e2656d93052.

It fails exactly the same way on 64 bit Windows too. Our 32 bit build machine,
an OpenBSD box, is fine. I'll have a look.

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?

Does this work on the command line?

Which gpg4win version?
Does this work on the command line?

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

Changed category to pinentry - this is a pinentry-gnome (ie. gcr) problem.

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.