Note that exactly same data and length computed by ssh_signature_encoder_rsa, including additional 0, reach:
https://github.com/openssh/openssh-portable/blob/V_10_2_P1/sshkey.c#L517-L537

2.2.53 was released wit VSD 3.3.6

Let's see whether Niibe-san still remembers the T7882 case.

Can you please test the patch below in your environment. That would be helpful.

Added to some debug logging and whenever login issue occurs new logic is applied:
https://github.com/gpg/gnupg/blob/bc7c91bee521e4adf3506ca32bf34177b84ce1c5/agent/command-ssh.c#L1482

Looks like indeed related to T7882. After reverting c7e0ec12609b401ea81c4851522d86eb5ec27170 I was able to make 2000 connections without any issue. Bringing the change back and retrying issue appeared within first 300.

I've already tried with verbose which gave no errors. That's why I moved to debug logging. With double verbose I don't see anything wrong either. Excerpt from log for relevant 100 connections among which 1 failed:

$ cat gpg.log | 
    sed 's/.*gpg-agent\[[0-9]*\] //'  | # remove date, time and process id                            
    grep -v 'ssh handler .* \(started\|terminated\)' | # appears to be mostly noise wit hex address
    sort|uniq -c
     80 new connection to /usr/libexec/gnupg2/scdaemon daemon established
     20 new connection to /usr/libexec/gnupg2/scdaemon daemon established (reusing)
    100 received ssh request of length 1
    100 received ssh request of length 208
    100 received ssh request of length 748
    100 sending ssh response of length 1
    100 sending ssh response of length 281
    100 sending ssh response of length 626
    100 ssh request handler for extension (27) ready
    100 ssh request handler for extension (27) started
    100 ssh request handler for request_identities (11) ready
    100 ssh request handler for request_identities (11) started
    100 ssh request handler for sign_request (13) ready
    100 ssh request handler for sign_request (13) started
    100 ssh-agent extension 'session-bind@openssh.com' not supported
    100 ssh-agent extension 'session-bind@openssh.com' received

You need to get a log form gpg-agent. Put this into ~/.gnupg/gpg-agent/conf

I'm not sure if there is any way for the add-in to know which way it was installed.

As noted by @ametzler1 pinentry-qt has such a fallback. Of course, we can try to improve the heuristics pinentry-qt uses.

I tried but couldn't reproduce it any more. Therefore setting it to invalid.

Before making subtickets for each application: I wonder if it is not all Kleopatra anyway? Isn't the security approval dialog basically Kleopatra?

The equivalent for invalid S/MIME certificates are not-certified *PGP certificates.
(Valid/invalid are not ideal as technical terms as they have a broad general meaning, too. I hope my usage here is correct ;-) It is what I gathered from an explanation given by Werner.)

Note: The invalid revocation certificate: Bad signature - rejected line is also shown on vsd 3.3.4, gpg 2.2.53 @ win10 (but revocation works).

feedback of @mmontkowski needed

Invalid certs (as stated in the status column in Kleopatra) are mainly S/MIME certs (e.g. with missing root cert, CRL check failed, etc). I haven't seen invalid pgp certs yet (might be e.g. very old ones with missing self signature).

Invalid and expired are different cases.

Not a good idea. Because then the user will open it with the browser and the browser loads all kind of additional data including drive-by malware. If HTML *mail* is shown by a MUA no links should be followed to keep information and the fact that it was read confidential.

I think locate mode is mostly meant to be used to retrieve a single key

We talked about this in our developer meeting on Monday. I have never experienced the problem because I use the Qt version only on Windows and for my own use I use the Gtk version. In any case I think that Qt and fltk should fallback to curses to cover the case of using the Pinentry for a system startup on the console (e.g. the g13 case) with later switching to a GUI. And of course for those users who switch between GUI and console.

yes, we should only ask for an update of the manifest if its content was changed. the message should indicate that.

Issue 1) should be implemented as already described (on error -> dialog to retry with "always trust" flag)