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.

The comment from aa above appears to be misdirected/spam.

@werner , I understand your poiont.

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.

I applied the change to libassuan.

Don't need to check macOS version. Simply, if it's not defined, define INADDR_LOOPBACK.
That's better. Because it can support other cases.

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.

So, this is VERIFY reset allows the host to implement the "force" flag we always had in the card for the first key. At least kind of, because malware can still suppress the VERIFY reset ;-). The integrated "force" flag requires the admin PIN, which is malware should have more problems to snoop.

For the record, the authentication status reset by VERIFY command was introduced in OpenPGPcard specification V2.2.
I think V3 card supports that.
Gnuk 1.2 supports this reset feature.

Yes. For the use case of GnuPG, it is better to support disabling (unauthorize) use of keys.
On the other hand, IIUC, the original OpenPGPcard implementation is designed/implemented under the influence of other smartcard usages.

The idea with the smartcard is that you can limit the time of exposure
of the key. Leaving the card accessible to the host is thus not a good
idea. Malware can simply snoop the PIN from the last operation and
then, at its own discretion, use the keys of the card. This can only be
avoided by using a smartcard reader equipped with a pinpad and able to
filter commands so that it is not possible to bypass the pinpad (which
is easy for the host).

Unfortunately, not all OpenPGPcard implementations support command to unauthorize use of keys.

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.

Using a smartcard it should be possible to set a cache-ttl value so that not only on-disk keys but also the PIN used for unlocking the key on the smartcard is not cached longer than the given period in cache-ttl. Until now you have to plug out and in the card by yourself to get this working. Alternatively you theoretically could set a config in scdaemon to power off the card after some time ("card-timeout). It could be a solution to set this config automatically if cache-ttl option is used.

@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:

In rP2b1fb2f30a94a967dacec298e3c7d8a80b4c3194#48919, @gouttegd wrote:

Could you expand on this slightly?

Let me summarize:
[...]
(just put grab on a single line in $GNUPGHOME/gpg-agent.conf).

Ok, I implemented this for Inline messages. The resulting armored literal data packet is encrypted as PGP/MIME message. I'm not sure this is what we want.

Implemented --unwrap stuff, too.

Please move this also to another branch.

Could you expand on this slightly?