Right. I was wrong assuming the code in 2.2 branch is stable (that is: well tested).

Per https://dev.gnupg.org/rG04cbc3074aa98660b513a80f623a7e9f0702c7c9#83517, it looks like the fix might be incomplete?

Thank you for the quick attention!

Although, we don't use our usual s-expressions we need to add a way to derive a keygrip from Kyber et al and also to wrap the key into an s-expression to that it can be stored by gpg-agent in its usual files. An exported new API to get the keygrip of a KEM key would be good to avoid encapsulation but for other purposes an encapsulation is still required.

That is simply because your XDG_RUNTIME is set to the same directory gnupg uses. See gnupg/common/homedir.c:_gnupg_socketdir_internal

Funnily enough, runtime sockets already adhere to the XDGBDS somewhat by using $XDG_RUNTIME_DIR/gnupg as their path, while everything else uses strictly $GNUPGHOME or ~/.gnupg with no other alternative. Of course, I completely understand that the priority for this is rather low, but I am still happy to look into providing a patch myself that would add these fallbacks if it would help expedite the whole process.

Seems to be a small problem with the regex used for extracting the gpg4win version number from kleopatra's version number. See https://invent.kde.org/pim/kleopatra/-/merge_requests/117/ for fix and details.

My suggestion is to define all filters in libkleopatrarc instead of defining some filters in the C++ code.

Portable Apps are a Bad Idea because they bypass important security mechanisms. In any case please tak such discussions to a mailing list and please do not use the bug tracker for this. The audience of bug reports is pretty limited.

Talked to werner about this. We will but the list of signed files into the Gpg4win repo proper to that signing is part of the normal Gpg4win release (of course only if you have a signing key configured)'

Isn't the kleopatragroupsrc just such a config file?

Implemented: https://invent.kde.org/pim/kleopatra/-/merge_requests/116 and https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/323

Quick hint how to test a fix given that the versions.gnupg.org currently does not carry an entry for gpg4win.

These actions/commands or, more precisely, the documents those commands show, are only available in the commercial GnuPG VS Desktop release.

Ingo came up with the idea to put all the filter definitions in a config file in the GNUPGHOME.

The validity column does not contain that information in case only the encryption subkey has expired.
As is the case if people extended an expired keypair via Kleopatra with VSD up to 3.1.26.

This is basically done although not exactly as proposed here.
But WKD and Keyserver search are now combined. With WKD search only if you configure keyserver "none".

Werner wants the import via gpg-agent

Thank you for the report. There was a problem in: rG845d5e61d8e1: dirmngr: Cleanup the http module.
Pushed the fix in: rG04cbc3074aa9: dirmngr: Fix proxy with TLS.

In master, I applied changes for include files which don't harm current target of MinGW-64.

It's true that under $GNUPGHOME (~/.gnupg/), there are multiple things: configuration files, user-specific data files (private keys, public keys, the trust database, and revocation certificates), user-specific state files (like the lock files and random seed), possibly runtime sockets, and executable/script for card reader. Some careful handling might be needed for making backup and doing version control for that.