Resigning as reviewer since I cannot close it, but want to have it off of my list.

Putting up for grabs and removing Kleopatra tag since for Kleopatra users this has been fixed (unless they manage to trigger multiple separate concurrent imports in Kleopatra).

Done for OpenPGP cards, PIV cards, and NetKey cards.

Hello Andre Heinecke,

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.

See also T6329

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.

RSA-2048 can still be used in de-vs mode if it's listed in the RSAKeySizes config entry.

I leave this open as ticket for the rest ?

I'm that user - only thing I can think of really is that I used the tool "O&O ShutUp10++" to restrict Win10 Settings. During the troubleshooting I reverted to the standard settings, but it made not difference.

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.

For the clipboard operations (encrypt and sign) we store the user's decision to keep the results open after the operation was completed. These settings cannot be changed in the UI currently.

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.

Can you therefore please clarify the purpose of the Libgcrypt LTS branch? My impression was that pairing the Libgcrypt LTS with GnuPG LTS was appropriate, based on both GnuPG and Libgcrypt LTS appearing on your downloads page at approximately the same time (from memory). Specifically, is there any issue using latest Libgcrypt 1.10.x with GnuPG LTS? Thank you.

See T6340 in case of build problems.

Will not be fixed because the only change is intentionally the export target for a regression test suite. The other fix is for the old FIPS RNG which is not used at all.

Thanks for the context Werner. This was missing from the commit which added the deprecation warning so all one could do is guess.

As I assume that many people have HTML emails still turned on, and have no crashes, there probably are more conditions that have to be met to trigger this crash.

Thought about this for a while and rephrased and thus repopened.
I think it would be good to remove or explain the sha1sum checksums in the announcements.
Whether they are replaced by something else, e.g. sha256sum is of lesser importance.

It turned out that this does not make much sense.

Kleopatra now runs the gpg/gpgsm processes one after another if multiple files are imported. (In fact, since we always try to import with gpg and gpgsm, this actually already happens when a single file is imported.)

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

Here is my fix:

Here is my change for libkleo Japanese Translation:

The attached patch removes the --supervised option from the example dirmng and gpg-agent systemd unit files.

Shouldn't we remove the sha1sum then as well? Or add an explanation?