success, thank you for the help!

In GnuPG 2.1, secret keys are under control of gpg-agent. Currently, it is not deleted by gpg frontend.
Please run:

$ gpg -K --with-keygrip

The only mitigation I can see for this is a better error message.

I think any existing script that assumes UTC should add an explicit Z suffix. (that is, i don't think the breakage is a big deal, and anyone writing scripts that needs this kind of precision will be more likely be thankful that we have a sensible, normalized interface).

It is pretty much confusing. When a user specify in YYYY-MM-DD format with no hh:mm:ss, it is interpreted as local time (noon of that day).
When a user adding Thh:mm:ss, it is UTC.

While I confirmed that GnuPG interprets YYYY-MM-DDThh:mm:ss in UTC (which should be interpret as local time according to ISO-8601), I don't know how we can fix this.
If I change the interpretation of GnuPG (possibly supporting the format with Z suffix and timezone), it may break existing script which assumes UTC.

Bug confirmed in rGa766a37290cf: Print keyid in gpg --list-packets..

When Thhmmzz is specified, no adding 12 hours, that's the intention of the code, I suppose.
However, the implementation is wrong, since the beginning (not supporting "Z" or timezone for ISO-8601. interpret the string as UTC).
I will take that, too.

Is it possible that this is related to T3278 ?

I think that adding 12 hours by parse_expire_string make sense.
The test suite should be fixed.
I will.

fwiw, i agree that GnuPG should interpret these as ISO-8601 strings. At the very least:

Nice find, @gniibe ! So this looks like a bug either in GnuPG's test suite, or in parse_expire_string, right? How do you think it should be addressed?

In the log, I found:

Possibly, timezone (of build machine) matters.

Please try this patch:

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...