Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.

@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.

The show error is due a missing translation. What happened was that the translation was marked fuzzy and this marker was removed not realizing that the string really changed. The change was "...in the GnuPG system" -> "...in the %s system" which had been done to allow for different gpg names.

Start from scratch on a german system, even when you do a gpg --version it shows it is in german. Then import a PKCS#12 container and the dialog is in english.

A wild guess is that the different envvar systems we have in use are the culprit. It is anyway time to get this straight.

thanks, @werner!

Okay, okay, I had in mind that we print them because we used to put such certificates into the ephemeral certificate storage because it is not possible to check the signature. But I reliazed that this changed quite some time ago and we can view these error messages as informative only. They are now not anymore printed int quiet mode. Well, for 2.3 - not sure whether I should backport this to 2.2.

Thanks for the fixes, @werner!

Done in 2.2 and 2.3. The issuer certificate thing is a real error message and thus it should be printed.

Other ways that gpgsm --quiet is not quiet:

Reopening this as I have seen such hangs multiple times during testing. When importing multiple keys with Kleopatra at once this can be reproduced sometimes.

This has been resolved with rOb05416e7bc41

The CRL states how long it is valid and we cache it for about that time.
OCSP responses are by definition not cachable but we allow for a clock skew of 10 minutes.

Its a year since I worked on the mentioned wait code change (wk/new-wait branch) and I more or less forgot about it. it will to risky to release that as 1.14 so this change and the fix to this bug needs to be postponed to 1.15. Sorry.

This appears to still be a problem, despite upgrading to libksba 1.4.0:

GnuTLS seems to have some CMS support; see https://gitlab.com/gnutls/gnutls/-/issues/227 .

Seems to be fixed now.

Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.

Finished if an existing key is used. See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples.