Ticket for the hang on file encryption: T8187: Kleopatra: File encryption with invalid S/MIME certificate hangs indefinitely

According to Werner, that should be:

Maybe those smime certs will do:

It needs to be clarified which kind of errors should be handled and which kind of S/MIME certificates should be allowed to be used for encryption:

• Valid certificates where the CRL check (or OCSP check?) fails
• Invalid certificates (e.g. because of incomplete chain/missing CA)
• Expired certificates

It would be used for key creation just like the legacy options PGPKeyType and RSAKeySizes were used (and still can be used but only for RSA with different key sizes).

How did you configure? If possible, please show us the configure options when you built.
Did it work in older version(s) of libgpg-error?

FWIW: Okay, gmime is still a wrapper around gpgme. After decryption it has the ability to get the used session key from the gpgme result structure. Thus, I have been on the wrong trail. The actual problem is not gpgme but more GnuPG's use of Libgcrypt or an actual regression in Libgcrypt. Well, Friday 13th.

Any hints where to find the actual crypto code which uses libgcrypt?

Maintainer of the FreeBSD notmuch port/package here. The steps below consistently trigger the problem on FreeBSD 16.0 (unreleased main branch), but there are no problems on FreeBSD 15.0. All my testing was on amd64.

Any hints where to find the actual crypto code which uses libgcrypt?

@thesamesam Thanks a lot.
I managed to replicate the failure somehow (for me, it fails at the importing the key).

I've attached notmuch-bug.log with debug-level guru commented out for gpg-agent:

I can reproduce it using Stuart's script from https://lists.gnupg.org/pipermail/gcrypt-devel/2026-February/006031.html.

Please tell us the information of your environment.
What the versions of gpg and gpg-agent?

Additionally to the fix Andre cited years ago, we also did some more changes recently in regard to how signed/encrypted mails are shown. Which are relevant for the inbox, too.
This issue should be fixed.

Hi, I've managed to reproduce this bug on the gpg4win-5 beta as well. I think the frequency has gone down, perhaps, but it is still present.

As there has been no more feedback on this for years, I'll close this.

If this is indeed a bug it won't be fixed in gpg4win 4. Thus a test with gpg4win 5 beta is highly appreciated. It would also be interesting to see what what version of gpg comes with Git.

Closing since the cause for this was identified.

I assume the problem has been resolved because we never got feedback that the problem persists.

Fixed in master: rGe7891225788a: gpg: Robust error handling for SCD READKEY.

Some would say it is a bug if keys are not shown - even if the algo is not known ;-)

scdaemon in this case was a broken experiment of mine (trying to see if I can get SoftHSM to work as the OpenPGP card). So this was not a normal, released scdaemon code.

I can replicate the problem.

What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute

by default we keep the unlocked secret key limited to this very tiny process (gpg-agent) which only does the secret key operations. That is I think the best decision. It is IMO not really a bottleneck since except for very small data bits the bottleneck is usually the hashing. What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute? And even then are you sure it is not your disk IO that is the bottleneck and it is in fact gpg-agent?

Why couldn't gpg-agent just fake these homedirs on its own?

Well this depends of course. If the "Hard work" is the actual signing it depends a ton on your Key. An ECC key will go much quicker then for example RSA4096 but IMO the "Hard work" when signing is the hashing and that is done in parralel for extremely specialized setups you could run multiple gpg-agents in different homedirs with access to the same key.

I create 1000 empty files, and sign then using GNU parallel+gpg and trying various parallelization factors. (CPU used is AMD 3700X with 16 threads.)

closing, as setting a password on a key without password works (at least in current gpg4win version). For improvement of the user guidance see T6436.

Hello Andre Heinecke,

Hello Andre Heinecke,

Thanks for the certificate, looks good as far as I can tell. I have trouble with CRL checks for your certificate as https://crl.sectigo.com/ does not work for me. But that should not be an issue when decrypting.

Hello Andre Heinecke,

Please attach the certificate so that we can check what is problematic with that certificate. I am changing this issue to wishlist as the solution here will most likely be that we have to extend the S/MIME capabilities of Gpg4win.

@aheinecke What additional information do you need ?

On the command line using:
gpg -o output.txt --decrypt "yourfile.asc"