I had a look into my \AppData\Local\Temp and found some 10,000 Files/Folders (nearly 100,000 files in total) with over 10 GB.
After deleting most of them, GPG4WIN 4.0.3 is working!

Small correction: We don't have replicas of our code signing key. I mistook this with out Authenticode signing key.

It's strange that the problem only occurs locally on one machine. I set up a test bench and did not experience the same errors as before.

Thanks a lot. Due to your log I have tried with a long username and umlauts and a dot in my username. My test name was Längül!ödiföäada.dad which is the longest that Windows allows. But It still works for me. Even if I create one or two gpgol_enc.dat files in %TEMP% It still works:

The fix did not work, the hangs occured later in testing again. After further debugging we found the issue to be that we did not Close the handles we inherited to the child.

... Logging active, standard, with email content and meta information

I have produced a log using 4.0.3.
See attached.

GnuPG requires threads but not gpgme.
We already had the same discussion about threads and libgpg-error more than one year ago: https://dev.gnupg.org/T5296

Push the change.

Thank you for your report. Next time, please include information of your target and configuration in the report.

In general I use my standard ed25519 signing token for all software. However, GnuPG VS-Desktop is signed using a Brainpool key named GnuPG.com (stored on a smartcard with 2 replicas) for the simple reason that it does not raise questions when ppl update their GnuPG VS-Desktop and run into a non-compliant key.

After internal discussion this will be moved to Wontfix.

I found the following issues while testing with NVDA:

1. In the Certificate Details dialog NVDA does not read the labels associated to the key properties when a property gets focus, e.g. it reads the expiration date, but it does not read the label "Valid until".
2. In the Certify dialog the "Advanced" expander lacks a focus indicator.
3. In the Certify dialog the explicitly shown tool tips are not read.
4. In the Certify dialog the explicitly shown tool tips are immediately closed if the mouse pointer is over them or if the mouse is moved a short distance.
5. When a dialog is opened, then a label that has initial input focus lacks a focus indicator.

This looks like a different but not too uncommon problem. For T6169 we need to get a PKCS#12 file to be able to replicate the problems - obviously that PKCS#12 should hold only test keys/certs.

This issue happens even if a user enters the correct password for the private certificate.

I think this is a duplicate of T4779 I am merging them because if it is not a duplicate T4779 is still the right issue because we need better error messages for PKCS #12 import

strange, I have not received one. Did it bounce somewhere maybe because of size? Encryption should compress this though.

To identify/locate the issue, you can try command line:

In the situation of a certificate about to be expired in the cache:

Thanks, @gniibe -- i agree that this change to put_cert should be helpful, when encountering a certificate that is already invalid.

TLS 1.3 requires much changes for NTBTLS.

Applied to master and 1.10 branch.

Ok, email sent

Could this be reconsidered, as a way to support "allow-external-cache" in pinentry-qt? I am trying to use pinentry-kwallet, which saves the passphrase in kwallet, but there is no checkbox if the underlying pinentry is pinentry-qt.

I believe that this error is caused by a software bug of Gpg4win. Please get back to me if you need additional details about this issue, thanks

Please, Last chance to add a log with Included file names (Include data checkbox) before the next release. Me and a colleague reviewed the function and don't find an issue with it. Otherwise I will only add a MessageBox error in that case for the next release.

It turned out that this is pretty important if you use a current version of scute; That one uses gpg-connect-agent to list all smartcards. And gpg-connect-agent will start and take over a remote socket used for the card.

Not for this release. This needs changes in GPGME and we should check and parse the KEY-ATTR-INFO directly. My Yubikey 5.4 returns this, too. I think Ingo should implement this properly and well tested.

As discussed with werner we want to have it for the next release as yubikey is very important for us.

Fully done in my opinion.

This is in for so long we can mark it as resolved. I had tested it on Windows.

Fixed