Yes this is windows. With the USB Stick I think it makes it more reproducable that bytesToWrite will return something. We also had reports that this happened on Network drives so its probably just "some added delay or something where the Windows Kernel does not do buffering".

The followup of this issue for libassuan is: https://dev.gnupg.org/T6324

I see the use to have an option to have a stricter "min-rsa-length", and which will be useful even in the future e.g. for 4096.

So the problem is occuring when the output is finalized (which happens after the GpgME Decrypt Result is signalled). And when there are still bytes to write in line 332 https://dev.gnupg.org/source/kleo/browse/master/src/utils/output.cpp$332

As you might have seen from the commits mkportable has been removed from Gpg4win.

From the NEWS assuan_sock_set_sockaddr_un was only added in 2014, years after the UIServer code was really last modified.

Btw. This is how Kleopatra creates the socket: https://dev.gnupg.org/source/kleo/browse/master/src/uiserver/uiserver_win.cpp$34 which does not use a function that would set is_socket=1. My naive fix would be:

My opinion here would be add the "import key from signature" and "put key in signature" in the automatition group of the main GpgOL config page and change the wording of "Import any keys included in Mails" to "Import keys from Headers and Attachments".

o.O have overlooked this since October.

This is most likely caused by an incompatible addon. See: https://wiki.gnupg.org/GpgOL/IncompatibleAddons

If no keyserver is configured GnuPG uses its default keyserver. "disable-dirmngr" would be the option to completely disable keyserver access but that is rarely used.

I think the current way is a good compromise. Turning this into a fatal error has also resulted in very many support cases.

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.

@ikloecker Well in the spirit of user friendlyness Kleo could assist the user by removing this added blurb. We already assist the user in using a different folder then the temporary folder for such files.

@ikloecker You are right, I only thought of public key import. Then lets serialize this. Might even make for a nicer Progressbar if we count the outstanding files.

In T4505#166390, @ikloecker wrote:

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

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.

For testing I have created a Gpg4win installer and only selected minimal installation and gpgme-json was there. Both in /bin and /bin_64.

Only just noticed that this was added incompletely, it was added to the build system but not linked in.

Reopening this as there still seem to be ways to run into a deadlock as was reported in RT#13361. While I still think this points to some issue in gpgsm, when Testing this I found the behavior of Kleopatra to be wrong.

Has been remedied. We should have noticed before the release but the heavy warnings you get only appear if the binary is downloaded from the internet.

This was an accident. Will be fixed ASAP.

Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

I do not really understand why this is necessary. The problem is that /nonfatal conflicts with our msi creation as there is no such equivalent in the wix toolset language.