In T6977#183049, @Karam wrote:

Uploaded the corrupted file.

Uploaded the corrupted file.

It seems to pass for me with gnupg-2.2.41 but fails with gnupg-2.2.42?

I need to come up with a better strategy here. --refresh-keys is a very useful command and it should do what the user expects. Maybe we can adjust the behaviour iff we detect that there is an LDAP keyserver.

Since there are some files that would simply have to be created each time under $GNUPGHOME, I've been thinking a bit more about what sort of approach to take for "fallbacks."

Mh, the problem is that this is really a speciality feature which KMail currently has, that you can configure for a contact to prefer S/MIME over OpenPGP even though you have both keys.

I'm not sure how to approach this.

Interesting. So the problem is not actually the Key-Type, but that the default key-type requires a Key-Curve parameter which has no value by default

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: