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.

A newline is required by the PEM standard.

Thanks, the mentioned OpenSSL option should be helpful.

A high level test description is:

1. Configure both gpgsm and dirmngr to use OCSP.
2. Import the responder signer certificate with gpgsm --import.
3. Use a certificate with OCSP responder extension present, or configure a default OCSP responder in dirmngr.
4. Configure your OCSP responder to identify itself with key ID (and not subject name)
5. Attempt to sign or verify with gpgsm.
6. You should get an error, with dirmngr logs showing that the responder signer certificate could not be found.

Thank you for a quick fix (despite this being a minor problem).

Do you have any test cases? Note that T3966 is due to missing support for SHA-256.

We only supported SHA-1 signed OCSP requests. Fix will go into 2.2.16.

Thanks to your very good analysis, this was easy to fix.

Interesting tinge: The main CRL of the dgn.de CA uses a nextUpdate in the year 2034 (15 years in the future) which would force dirmngr to cache the CRL until then. However, the CRL of the intermediate certificate has a nextUpdate only one month in the future. There is currently no entry in that second level CRL, so their idea might be that an updated second level CRL will also trigger a reload of the main CRL. I have not checked how we implement that in Dirmngr but I doubt that such a thing will work for us and that it is in any way standard compliant.

That was obvious. rG6fc5df1e10129f3171d80cf731f310b9e8d97c26 fixes this.

When doing a "gpgsm --with-validation -k foo" (assuming you have a cert foo) gpgsm now goes into a loop and prints the certficates that match "foo" over and over again. I have not tested if it was caused by this change but I think it is likely.

I imported 39 certificate files at once with Kleopatra with about 700 certificates and it worked. Took a long time though so It would be nice if Kleopatra would show a progess indicator or some indication that the import is running. But this is a different issue.

Will give you more detailed info about your certificate. For even more details use --dump-chain instead of --list-chain.

The last lines that the process currently holding wrote in the log:

To reproduce this issue I started Kleopatra with an empty GNUPGHOME and imported 10 S/MIME certs at once (which spawns a gpgsm process each) with enabled logging.

Thanks for the hint on the existing OID I already looked into that and planned to use one from the GnuPG arc, But an existing OID is better. I still need to figure useful workflows but something like this will be useful for smartcards..

I forgot: Instead of importing the missing internal CA, this works:

I agree, the question is which CRL is checked when how. Maybe there is some mistake on my side. Here is a recipe for Debian:

I don't think this is a bug. Failure to encrypt when CRL check fails is expected.

Ouch indeed. Looks like you run into a "hanging" gpg-agent situation in that case our main background process is blocked and all other processes wait for it to respond and nothing works anymore.
This should never happen and we need to fix it. But so far we have not found a way to reproduce it.

Looking at other threads I found the problem in some .lock file in my gnupg directory. One of them was locked by a running process and I was not able to delete. So I opened up task manager and I had dozens of gnupg related processes running. I killed all of them and removed any .lock file.
This way Kleopatra started again but the certificate above (aruba) was not present in the imported ones. And, of course, I'm not going to import it anymore, will use my sixt sense to trust certificates...

The exact file that created the lock is attached

The only action I can do is quit the program telling it to stop the background actvity, but I cannot use it anymore...

Ouch, worse problem here. After closing kleopatra telling it to stop doing whatever it was, I restarted the application and now it's stuck in "Loading certificate cache"

The certificate was defintely missing the tag lines, thanks. I also tried opening the certificate from that page (Windows has no problems without the tag lines) and exporting it explicitly as base64, and the output file is fine.
The problem is that the import now seems to go well, but no certificate is imported at all. I tried several times and the import box just closes after selecting the file.
I tried to close Kleopatra and it says there are ongoing background operations. At least 15 mins passed between the import and the closing tentative.
Actually, it is stuck doing something.

Thanks for the report.

Btw. I only noticed this now as I always had "disable-tor" in my config but recently removed it for testing.

We also need to fix for encryption and signature in CSR.

Thanks for that summary.

Since it seems there is a renewed interest in adding ECC support to GpgSM (as indicated by the T4098 feature request), I would like to write down here more details about this task.

See also T4013 which is about ed25519 key support

werner,
I'm the spanish user. Are you also setting default ocsp responder option?
Setting only ocsp_signer doesn't worked, there are several CA's with diferent ocsp responders.

The reporter said that it did not work for him.

A list of SHA-1 fingerprints for the valid certificates. With our without colons.

@werner what should the contents of the file look like?

I had to look it up in the code and man page too ;-)

Good to know. I thought that ocsp-signer was only used if ocsp-responder is explitly set. I've suggested the workaround in the Message Board.

Is using

In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.