Moving back to WiP and setting status to Testing. Moving to QA shall be done when an installer to test this is available. See https://dev.gnupg.org/w/gpgcom/

Can you make this corrupted file available to us?

Hello,
So after testing on gpgme-1.17.1, with run-verify under tests as you mentioned, with corrupted file it hangs forever.
Now we can say it's a bug in gpgme_op_verify.

No, I am not aware. I can't remember whether PGP once had such a bug because @dshaw did most cross-testing and fixing for PGP bugs. I would suggest to remove any such checks. IIRC, this was introduced by PGP 2 to speed up signature checking. 30 years ago RSA operations were quite expensive.

I was wrong for the semantics of proxy->outtoken. It is zero when run_proxy_connect is called and enabled during the negotiation.

@hlein Thanks a lot for quick testing.

Thank you @gniibe! Applied the rG848546b05ab0: dirmngr: Fix the regression of use of proxy for TLS connection. changes here, and 2.4.4 works here now.

IIUC, the code for keep_alive is for negotiation of proxy. If so, something like this is the fix:

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.