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.

I created T6842 for the "Cleaning Kleopatra directories on startup" so that we can close this task once ebo confirms that all is fine. Usually I would close this task myself since I already tested it. But well we have QA now ;-)

Considering the design of gpg-agent which focuses on private key operations and data, it would be better to enhance the gpg-agent protocol to inquire public key data of any format defined by the client (including ECDH KDF parameters of OpenPGP). I mean, instead of storing data in the key file (originally designed for private key + some additional data), we will enhance the protocol.

That is a feature. Consider the case that ~/.gnupg is on network file system and thus possible in use on several boxes. Thus before we remove stale lock files we do not only compare the PID but also the hostname. Granted, this is rare but we have had such cases in the past with locks.