I found a solution for master and 2.1.19 which minimizes the risk of regressions:

I think this is now resolved.

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

Thank you.

I uploaded the certificate files. For a test please do the following:

Sorry, a fix didn't made it into 2.2.18.

I give this normal priority even if it is a whish because I have the same whish and already have some code around that would make it more comfortable, especially if it is used directly in GpgOL.

Thanks for the sample certs. I noticed the posts but had not the time to look into them.

It appears (for me) correct behavior.

Works for me! :-)

I have a larger change for the wait code in the works. This will go into 1.14.0 but not in 1.13.1

I had to patch strace to follow threads but not forks (P8) and then when built with support for -k I tracked it down: In the inbound handler we close the fd immediately on EOF. However the upper layers don't know about it and a select fails with EBADF. Of course we could ignore the EBADF, figure out the closed fd and restart. The problem is that another thread may have opened a new oobject and that will get the last closed fd assigned - bummer.

Just noticed that due to me failing to properly understand re-entrant locks the run-thread test is broken at least on windows in that it never waits for completion. So running out of filedescriptors is to expect. I'll fix the test.

My observation from running the verify threaded test on windows is that it does behave differently. The EBADF does not occur.

Something(tm) closes an arbitrary file descriptor behind our back. Not easy to track down because strace can not trace only threads - it always wants to trace all children as well - which is a bit too much and leads to other problems.