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.

In T6832#179438, @ebo wrote:

VS-Desktop-3.1.90.300-Beta: The executable is now found.
Therefore now the details of the signing key are listed when clicking on "keys".

But the keys for which the message are encrypted are not listed after clicking on "Details" in the first blue frame.

After clicking all "links":

Tested on Windows with Kleopatra and 2.2 and with gpgme and 2.4 on Unix.

The "Load Certificates" button still remains greyed out if nothing changed, i.e. if no new certificates could be loaded from the card. This could be changed, but pressing "Load Certificates" multiple times won't magically fix loading the broken certificates.

Okay, I known do the same what we do for a single root certificate, that is mark it as "not trusted" ('n').

Should really work now.

Looks like ReaderStatusThread assumes that the data for the card didn't change. Therefore the card view is not updated (as before the changes for this issue).

Aha, the certificates are listed in the certificate view, though. And when you remove the smart card and re-insert it the keys are then listed without having to press the "load certificates" button.

For the X509 brainpool test cards I used it does not work in VS-Desktop-3.1.90.300-Beta . After clicking "load certificates" the button remains greyed out:

I create 1000 empty files, and sign then using GNU parallel+gpg and trying various parallelization factors. (CPU used is AMD 3700X with 16 threads.)

Still no response after more than 2 years?

VS-Desktop-3.1.90.300-Beta: The executable is now found.
Therefore now the details of the signing key are listed when clicking on "keys".

It's true that for KEYTOCARD command, there is optional argument for ECDH.
My point is that for PKDECRYPT command, it will be needed to add mechanism for getting such a parameter (when we use KEM API in gpg-agent).

Nope, The gpgconf --kill keyboxd hangs too, if I see right, while waiting for agent:

$ strace gpgconf --kill keyboxd
[...]
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2d74fe2a10) = 3244
wait4(3244, 0x7ffc9836e364, 0, NULL)    = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

In T6839#179343, @aheinecke wrote:

Wait,.. I misunderstood this issue B81CE112B26A8EA8BE7B95D2E375339BF4C51840 has no encryption subkey o.O

We already have the ECDH parameters for OpenPGP in the gpg-agent API. The question is how large the data for PQC will be - likely we need to use an inquire already for this reason.