In Kleopatra/src/dialogs/subkeyswidget.cpp there is already a context menu for subkeys.

• - it get stuck with empty window

Or when there is no name the email will be taken:

Hi, yeah its complicated for Kleopatra to detect the defaults as they can be set both in Kleopatra config and GnuPG config. The GnuPG config overrides the Kleopatra config. Kleo has code to handle this but not when it adds the comboboxes to the GUI. So I've just removed the "default". We only had this for RSA and DSA / Elgamal, for ECC we did not indicate the default.

Probably the same as T4257

The default for GnuPG 2.2 is still 2048 (Debian changed that in their distributed version). The reason for this is that we don't want to generate such keys but move on to Curve25519 for the new defaults.

Cool, thanks for fixing this!

Argh, I had overlooked that you even mention a pull request.
So Apologies that I did not attribute the fix directly to you.

Thanks for the nice report. The fix was completely straightforward, I just didn't think about rich text when I implemented it.

Works nicely

"Wyszukaj na na serwerze..." has been changed to "Wyszukaj na serwerze..." and should appear in the next release of Kleopatra.

It'll be fixed soon. Please use https://sourceforge.net/p/kdei18n-pl/mailman/kdei18n-pl-uwagi/ next time.

Thanks for the report.

Your guess is correct, but as this hole "Wizard" thing uses Qt Regular expressions its not super quick fix without having to introduce new strings etc.
So I just reduced the length. The new key generation in Kleopatra is pending a rewrite anyway. Requires way too many clicks ATM.

Seems like this is applicable to other binaries as well:

I've tested this issue on my Windows10 laptop.

Added variable value

set language
LANGUAGE=en_US

I launched the Kleopatra again. I did not notice any changes.

Thanks for your report. Yes this is sadly a known issue. Our backend system has it's own localization that uses the system language and does not care about the Kleopatra configuration.

I don't have a Free BSD. Can you please try out the patch that I have appended to https://bugs.kde.org/show_bug.cgi?id=415168 ?

workaround:
edit gpg.conf and dirmgr.conf manually
rem proxy in dirmgr
insert https keyserver in gpg

well, so far it`s win 10 with 3.1.11

The info from your report iis a bit scarce; we would need more to replicate this and also the version of the software and the OS you are running.

I'd like to re-report this bug for version 3.1.11-Gpg4win-3.1.11
in Windows 10 version 1809 build 17763.1039 and version 1909 build 18363.657.

Hi Andre, did you already get anywhere with this task? Thanks a lot in advance, Joachim

The Name field in GnuPG needs to be at least 5 _bytes_ long. Given that UTF-8 is required for Hangul, a 3 _character_ name is at least 6 bytes long and thus passes gpg check. The Name field is also optional and the whole test can be skipped using --allow-freeform-uid.

This is fixed in Gpg4win-3.1.11

Thanks for the report.

Will be released with 3.1.11

This is done in 3.1.11

Without --expert my proposal for full-gen-key would be:

Maybe it is the same issue described in https://dev.gnupg.org/T4717 ?

This is generally the better tracker to report Gpg4win / Kleopatra issues. The git systems are linked in a way that I can both automatically add a commit here and in the KDE tracker.
I just noticed the KDE report a bit quicker because there is less traffic, but I would have seen it here within the day.

I give this normal priority even if it is a whish because I have the same whish and already have some code around that would make it more comfortable, especially if it is used directly in GpgOL.

Strange. Can you please go to the command line (cmd.exe) and run gpg --verify "c:\<path to>\gpg4win-3.1.10.exe.sig" "c:\<path to>\gpg4win-3.1.10.exe.sig"

This pretty much matches my test setup. As the crash is in GPGME it is out of Kleopatra's hand. So I'll try to write a test that repeats such a signing for lots of times. I think this is probably some random race condition.

I don't think I can reproduce it, at least it didn't happen anymore after restarting and continuing the imports. AFAIR it happened after importing the "Master Key", during trying to import the "Release Key" from https://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html
Ah and maybe one more hint: I have several keypairs, so the dialog for choosing the keypair to be used appears in the next step.