Tue, Mar 2
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.
Mon, Mar 1
@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.
Fri, Feb 26
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.
Thu, Feb 25
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.
Wed, Feb 24
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:
Jan 27 2021
Jan 12 2021
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.
Jan 11 2021
Jan 8 2021
This has been resolved with rOb05416e7bc41
Jan 5 2021
Nov 18 2020
Nov 16 2020
Aug 25 2020
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.
Aug 19 2020
Jul 16 2020
Jul 15 2020
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.
Jul 14 2020
Jun 11 2020
This appears to still be a problem, despite upgrading to libksba 1.4.0:
May 27 2020
GnuTLS seems to have some CMS support; see https://gitlab.com/gnutls/gnutls/-/issues/227 .
May 19 2020
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.