by moving the KUniqueService before this and with the change b58cf129f the priority is reduced. It will still take 200ms so we might want to do something about this but it is not prio high as the 200ms are only on first run.

I do not think that this is an issue after analyzing procmon timings. It is only an installation time issue. For that there is no real reason to spend much effort on this.

Note to self after spending some time searching again for the documentation I saw previously about this: https://learn.microsoft.com/en-us/windows/win32/shell/context-menu-handlers#suppressing-verbs-and-controlling-visibility

I am closing this directly as this is an obvious removal of something that was previously disabled by configuration.

Good solution. I tested it.

Right, I think with that you could even go down to 1024 or 512 (or does gnupg block this?). Its better to block this in de-vs mode as it says in our documents somewhere that we prevent generation of non-compliant keys at least in the GUI.

My last idea with this ask was that we should reuse the Handler from GpgOL. Because that one is very simple and the difficulty is not the mime parsing, which KMIME could do but the whole complexity the objecttreeparser does.

kwatchgnupg translation commited as revision 1641797 I leave this open as ticket for the rest ?

Thanks commited this to https://websvn.kde.org/trunk/l10n-support/ja/summit/messages/libkleo/ this should then be automatically arrive in the po/jp subfolder of libkleo. But I keep it as testing to check if this actually was done.

For now that we do not want to push for more WKS support with gpgcom, as this will depend on adoption of WKS. So I am resolving this issue.

Since the issue T6328 described an issue with high pirority which would be fixed by this issue I am raising the prio here.

@ikloecker the proper fix for this would be T5478 so you do not have to spend time looking for this, we will remove the Process Input / Outputs of Kleopatra altogether.

We have discussed this and what we think would be the best solution would be to have an extension in the engine-gpg of GpgME either through a flag or through a new API to use gpgtar directly with --encrypt and decrypt. This should behave exactly like the gpg encrypt / decrypt / verify functions but would avoid the need of Piping in Kleopatra. It is a fairly recent development that gpgtar can do the crypto operations by itself so this is why this was not done initially.

Thanks! I don't understand why your fix helps as Kleopatra never calls assuan_socket_connect on the server side, but it helps. :) So this is probably called indirectly and I don't see it.

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.