Please try: rA87c2bb5708ff: We can't support fd passing, if the system doesn't support it.
It disables the particular test.

I think that file descriptor passing is not supported on Cygwin.
We should disable the feature of libassuan.

It will be in the next release (2.4.4).
Thanks for reporting.

The description of this bug report is not correct.
_POSIX_C_SOURCE should *not* be defined to use INADDR_LOOPBACK for the system.

With following files, I managed to emulate similar experiment. My intention is to replicate.

For me, I cannot replicate this issue with 2.1.20, either.

I tried to reproduce the problem with gpg-2.1.22 or later, but I couldn't.
What I did was:
(1) Prepare expired key of 2D182910, by removing three signature of current public key.
(2) Set "ultimate" trust with the key.
(3) Import current public key of 2D182910.

Let me explain the situation.

No, there isn't any error message or output, and it not accept any input.
Here is a GIF capture, but may not helpful.

@aheinecke thanks for your findings.

I suspect CRL / Root certificate fetching because it works after you once manually investigated the certificate chain through -> Properties -> Digital Signatures.

dirmngr is meanwhile an integral part of GnuPG. The old 1.1 dirmngr is entire obsosolete and won't do what gpg expects from it. To better diagnose the problem you can do this:

Thanks. That reminds me again that a GPA release is due.

Given no feedback, I'm closing this issue.
If there is still problem, please reopen.

In T2919#102889, @stbuehler wrote:

I think bad.trace is very similar in the errors (chan_9 instead of chan_7); the difference is probably that the "bad mail" is not using a detached signature (possibly even encrypted), so mutt cannot find the body without actually decoding the message through gpgsm; the "good mail " is using a detached signature, and the body is the first part of a multi-part message which mutt can decode itself; it still can't verify the signature.

I recall something about this on our mailing list.

I think bad.trace is very similar in the errors (chan_9 instead of chan_7); the difference is probably that the "bad mail" is not using a detached signature (possibly even encrypted), so mutt cannot find the body without actually decoding the message through gpgsm; the "good mail " is using a detached signature, and the body is the first part of a multi-part message which mutt can decode itself; it still can't verify the signature.

In T2919#102001, @stbuehler wrote:

I just had a look at good.trace and it seems gpgsm --server exits instantly (chan_7 <- [eof]). The path seems to be correct though (/usr/pkg/bin/gpgsm), and /usr/pkg/bin/gpgsm --version reads (the first 79 bytes):

gpgsm (GnuPG) 2.1.18
libgcrypt 1.7.6
libksba 1.3.5
Copyright (C) 2017 Free Soft

The --version call passes the full path in argv[0] (but the full path is always passed as first argument to execv, so it shouldn't make a difference).

Sadly it seems there is no error message from gpgsm, and also the exit code isn't shown. Maybe you could try running gpgsm --server manually; it should greet you with OK GNU Privacy Guard's S/M server * ready. An strace log might provide more insight why gpgsm --server fails.

In Fedora, they use this patch:
https://src.fedoraproject.org/rpms/libgcrypt/blob/6c13b08816b206b3ff2bab09fe55157cb3417fd1/f/libgcrypt-1.8.0-build.patch

IIRC, rfc2440 did not forbid partial length encoding for key-material so gpg could use that. rfc4880 limits partial length encoding to non-key-material which causes this error message.

Well, I'm able to reproduce this issue on Parabola. I was also get a different error when I turn off my vpn: `server indicated a failure```, but now I get the dns error again.

elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
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: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
elonsatoshi@tyger ~> sudo rc-service openvpn stop
[sudo] password for elonsatoshi: 
 * WARNING: openvpn is already stopped
elonsatoshi@tyger ~> pidof openvpn
elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net
gpg: using character set 'utf-8'
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: /home/elonsatoshi/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net
gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr>
gpg: error searching keyserver: Connection closed in DNS
gpg: keyserver search failed: Connection closed in DNS
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

FWIW,
the issue might be related to a key form Gentoo, which was expired but was then later renewed (at least it is no longer expired).

It even worked now (few hours later) :

Well, I'd expect gpg not to alter my digest/compression preferences when changing my cipher preferences and vice versa. So if a user's going to have to lose his previously set preferences for a key in this manner because that's the only reasonably viable way of maintaining backwards compatibility, I think it would be appropriate to let him know beforehand and also suggest that he set it all up at once (as I've so described above) so that nothing is lost in the process.

The way the setpref command works is implementation specific and thus the OpenPGP standard is irrelevant here
.
Are you requesting a change in the behaviour of the setpref command? That would not be easy to implement for backward compatibility.

Can you please try 2.1.23 ? We might have fixed that already.

@aheinecke is completely right. I just copied from Outlook's "show source".

OK, thanks for the info.

Sorry for the delayed response. I am in fact on pinentry 1.0.0, and haven't tested master yet. Looking forward to the patch!

Nice talk, just watched it.

In T3206#99005, @werner wrote:

1.4 has build fixes for NetBSD. Thus I _assume_ this bug has been fixed.

@aa can you please try npth 1.5 ?

I think this is a duplicate of T2416 please let me know if you still see the crash with the current beta / release candidate of gpg4win-3.0

This is what you get if you "show source" in Outlook so it's only the headers.

Is that really the entire mail? I can see only the header of the mail but not the body. How did you copy the raw mail?

Please see my comments on rM9f24e6c9010e171fd11c5cdac797cb8ce2e501dd

I merely said, that we won't replace libtool by the upstream version because that lacks other important changes we need. Upstream was not willing to integrate our changes for Windows support and also introduced a lot of other regressions as well as dropping support for some platforms. Thus we need to maintain our version.

I just realized that my fix for T3253 was incomplete, it only works if grabbing is enabled. With GnuPG Agent not requesting grabbing by default since 2.1.23, that would make the fix useless in the default configuration. Coming with a new patch soon...

Please try again with a recent version of GnuPG. We had a dozen more releases since 2.1.11 and we can't spend time on trying to replicate bugs which may have already been fixed in the last 18 month.

So it fails after a timeout. Which probably means that the conf->sync calls timeout which probably means that some gpgme process call to gpgconf hangs. Maybe some IO Flush that does not happen correctly on MIPS. But this is pure guessing.

Talked with Jochen and tested this. Jochen's test forwarded the mail so he ran into T2854

Unfortunately, even building for two Python versions is a bit of a hassle with the existing autoconf framework for Python. I did that when porting the Python bindings back to Python2 after we decided to also support 2 so that people could start to use our bindings even if they still need Python2. I don't see us extending it for more versions.

Merged, thanks for the reminder.

I can't reproduce this issue. I've imported the attached mail with KMail and synced the folder to outlook.
GpgOL did decrypt the mail. It did not set the category correctly (These were two other bugs which I've fixed now) and displayed the wrong status information but decryption happened.

I suspect this is a duplicate of T3253, where the same behavior (non-floating pinentry dialog) was observed under both the i3 and the Awesome tiling window managers. This bug has been fixed in master and the fix will be part of the upcoming pinentry-1.1.0 release.

this is also https://bugs.debian.org/866555

This is probably broken since Werner enabled descriptor passing by default in 5090f6f24. The analysis in https://dev.gnupg.org/T2919#99901 is correct, but it's not enough to put the operational error in the right place. Also, the calls to _gpgme_wait_one have to be replaced by _gpgme_wait_one_ext. The change overall will be somewhat destabilizing.