I have done testing using my QES certificate with all combinations of the two options.

The culprit seems to be commit rO6cb4ccf4d8db03e9922984d9c5f5bf7f8806954d but a brief inspection does not show any problematic code. Thus this might be due to an Outlook peculiarity.

You may also specify a mail address in which case gpg tries to find the best matching key. For example the latest key with that mail address. See gnupg/g10/getkey.c:get_best_pubkey_byname

Thanks for reporting/requesting.

I see from your other report that you are running a proper libgcrypt. But I think I spotted the bug: ECC+Kyber should not be displayed when adding a key. It is used for creating a new key ECC as primary and Kyber as subkey.

Nope: There are many different error codes returned, Kleopatra may want to map them to a common one.

Can you please try with gpg4win-5 beta: https://www.gpg4win.org/version5.html this makes it easier for us to see the reason. Deinstall gpg4win first and note that version5 is 64 bit and installed under Program Files (w/o (x86)). If it still does not work please add

Ooops. we already got a ticket for this.

Well, I will re-use this as a feature request to add this feature. Workaround is to list the key with --with-keygrip and backup the ~/.gnupg/private-keys-v1.d/<keygrip>.key files.

Please run gpgconf -V to which tells also the Libgcrypt version and more.

The problem is likely the gpg which comes with Git on Windows. Depending on where they are in the %PATH% a wrong one will be used. Please run gpgconf -L to check that the correct version of gnupg is used. I have never used git on Window but I would suggest to remove the gnupg binaries which come with Git and adjust the gpg.exe name in the global config.

A quick check with passing ASSUAN_PIPE_CONNECT_DETACHED does not changed anything.

I wonder whether rA3bccb33ccd9028ff505d9979fd6c8a37393b892d which changes Assuan's waitpid function for Windows is well aligned with the my_waitpid in gpgme's assuan-support.c (which does nothing). gpgme creates a detached process in most cases but for gpgsm assuan_pipe_connect is used without the ASSUAN_PIPE_CONNECT_DETACHED flag.

Another data point is that the faulty versions use libassuan 3 with a slightly changed API. May one of the follwing chnages cause the problem?

Someone should test whether gpgol2 is able to reencrypt all subfolders of a given folder. The file reencrypt tool (current name "recipients" "hugh") does this already.

Thanks for testing.

That look s like a problems with logging to stderr in --server mode. On Windows fds 0,1,2 are special.

The advantage of using a fingerprint for referencing a key is that there won't be any collisions in the keyid. Further this unifies the schema with an LDS (Windows) installation where DNs must anyway be unique. But take care the client needs to support this new flag. This will be the case for gnupg >= 2.5.12 (cf. T7756)