Problem is that Kleopatra uses the latest libassuan from Git and not the released version. Replacing the libassuan DLL with the one from the gnupg directory fixes the bug.

Missed some, will post an updated patch.

The debug output is

[2560] org.kde.pim.kleopatra: Checking Ui Server connectivity...
[2560] UI server not running, starting it
[2560] org.kde.pim.kleopatra: UiServer: client connect on fd  1528
[2560] org.kde.pim.kleopatra: UiServer: nonce check failed
[2560] org.kde.pim.libkleopatraclientcore: Could not find  "kleopatra"  in PATH.

which means that libkleopatraclientcore couldn't start kleopatra, but at the same time the UiServer seems to be running? Okay, maybe the lines are in wrong order and the connect doesn't fail because the server isn't running but because of the wrong nonce.

The actual problem at hand is that the nonce is not correct. The UI-Server is actually started but if a client (or the self-test) connects the connection succeeded but then the server needs to check the nonce which does not match. Procmon shows that there is only one nonce writen - so the problem might be that the server has different copies of the nonce.

AFAIU, gpgrt-config works well now for the multilib MinGW target.

I*m sorry, but I haven't found a way to determine what version of gnupg I am running. Just in case things got confused, I am not the thread opener, my version of gnupg is not whats been stated in the opening post but rather whatever is current on Arch Linux: Linux 6.0.11-arch1-1
I ran gpgsm --version though which returns this:
gpgsm (GnuPG) 2.2.40

Please update to a recent gnupg versions. 2.3.3 or if you really need the LTS version use 2.2.40. Instead of using a log you can import on the command line:

After years of using S/MIME I ran into a strange situation importing my new S/MIME certs to Kleopatra yesterday which ultimately led me to this thread.
My case is slightly different because my original passwords were short (2w7g9r1e and 2y8m7i5t), but it feels related so I thought I'd share nevertheless.

I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.

The current WKD/WKS draft offers no direct guidance to WKD clients about the type of filtering they should do.