These seems to be windows related bugs and it even seems to only appear with mingw builds of Qt and not MSVC builds according to https://forum.qt.io/topic/89997/using-colour-emojis-as-a-substitution-font-in-windows/12?_=1701253977832&lang=en-US :(

In GpgOL at least I have an API call to query the display language of outlook. I just need to pass it through to gpgme early and forgot about it. Also I don't think this would actually help completely if gpg-agent is running already.

Currently, the "Loading certificates" window is shown as long as gpgsm --learn-card runs. Instead of showing this window longer we should probably add some general progress indicator to the smart card view (e.g. in a status bar), so that the users see that Kleopatra is updating/loading information from the smart cards.

And another question: in the GnuPG code on the master branch I saw that algorithm identifiers for ML-KEM with Ed25519 and Ed448 are already defined in the code base. Do I understand correctly that the maintainers prefer the inclusion of these two algorithms and not necessarily the inclusion of the ones based on ML-KEM with ECDH using NIST or Brainpool curves?

Werner said it is ok

Some technical details:

• KDE's ki18n uses the LANGUAGE variable to set/get the language to use. On Unix, we simply use QLocale::system(), but on Windows and macOS we look directly at the LANGUAGE variable because Qt ignores this variable on those systems. See https://invent.kde.org/frameworks/ki18n/-/blob/kf5/src/i18n/main.cpp#L63
• KDE's kxmlgui reads the application-specific override language from the file QStandardPaths::GenericConfigLocation + "/klanguageoverridesrc" and sets the LANGUAGE variable accordingly (which is then picked up by ki18n). Example from my system:

[Language]
kmymoney=@ByteArray(de)

Regarding the format, =de would probably also work.
See https://invent.kde.org/frameworks/kxmlgui/-/blob/kf5/src/kswitchlanguagedialog_p.cpp#L64

works with VS-Desktop-3.1.90.302-Beta:

works with VS-Desktop-3.1.90.302-Beta, very nice!

Raising prio in reaction to some customer feedback

assuan_pipe_connect, etc., is outside of my comfort zone. Somebody else (@werner ?) should check how to prevent two gpgsm's started via gpgconf --launch and assuan_pipe_connect (if that's what happens).

fixed in beta302

What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute

Fixed in the according repo. The sentence structure made it easy to just replace the word README with pkg-licenses.txt

Ah, forgot about the license text in the installer, I hope that I can do an easy search and replace.

by default we keep the unlocked secret key limited to this very tiny process (gpg-agent) which only does the secret key operations. That is I think the best decision. It is IMO not really a bottleneck since except for very small data bits the bottleneck is usually the hashing. What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute? And even then are you sure it is not your disk IO that is the bottleneck and it is in fact gpg-agent?

I guess that the second instance is started by gpgsm_new (engine-gpgsm.c) via assuan_pipe_connect.

Why couldn't gpg-agent just fake these homedirs on its own?

We have addressed all comments regarding ML-KEM (Kyber) and KMAC. Currently I am working on the GnuPG integration of the the ML-KEM composites. For that purpose I will need a branch of libgcrypt with both ML-KEM and KMAC. I am not sure if you are considering to integrate the ML-KEM version already now before the final NIST standards are release. Some libraries do it, for instance Botan. Appropriate naming of the algorithms can ensure that there arises no confusion which version of the algorithm one is using.

When I do a search which is found on the keyserver, only the one without the multiple backslashes comes up, this seems to be started via gpgme call.
When starting again without a dirmngr and searching for a key which can only be found via WKD both entries appear in the taskmanager after only one search. The same is true if the key can be found in neither place. It seems the backslashes are associated with WKD and start is probably via gpgconf.

Well this depends of course. If the "Hard work" is the actual signing it depends a ton on your Key. An ECC key will go much quicker then for example RSA4096 but IMO the "Hard work" when signing is the hashing and that is done in parralel for extremely specialized setups you could run multiple gpg-agents in different homedirs with access to the same key.

Thank you very much on behalf of our S/MIME users. This also makes it easier for us in the frontend to show a consistent UI.

further improvement after the 3.2 release

One proces per user is normal but the two for ebo-ad are strange. Especially the one with the multiple backslashes. I wonder where that came from. Can you try to find this out? e.g. have taskmanager open while you repeat your test and check when it comes up.

I can confirm this

I can at least confirm that in VS-Desktop-3.1.90.300-Beta a file pkg-licenses.txt is included, as mentioned in the about dialog.

With VS-Desktop-3.1.90.300-Beta I do not any more see more than one dirmngr for the test user who is not in the windows test-domain.
But I still see 2 processes for the domain user. Which is less than before. Task manager for all users:

Fyi, Carl already, asked me to include that in our build so I will add this.