The minimum fix avoids changes needed, thus, a bit confusing as a whole.
Here are better changes:

Minimum fix is:

Well, I don't think we'll add platform-specific X11 code to pinentry-qt just to check for an invalid DISPLAY. We are using Qt so that we don't have to deal with platform-specific stuff. I have no intention to look into this and, given Wayland, investing any more time in X11 feels wasted. We might accept a patch that can be used by all GUI pinentries to check for a usable DISPLAY.

"ikloecker (Ingo Klöcker)" wrote:

ikloecker added a comment.

How is "invalid DISPLAY" defined? `DISPLAY=invalid`? Anything that's not `DISPLAY=:<some number>`? Why do screen and tmux have to use an extra-wurst?

[...]

@werner I can confirm that we've tested the patch and it seems to fix the issue in our setup.

Applied to master to be release with 2.5.19.

Apparently, DISPLAY is hostname:displaynumber.screennumber where hostname and .screennumber are optional and where hostname is a hostname or maybe host/unix. Does hostname include IPv6 address literals? Anyway, I guess the only sensible heuristic is to consider any DISPLAY value that contains : as valid.

How is "invalid DISPLAY" defined? DISPLAY=invalid? Anything that's not DISPLAY=:<some number>? Why do screen and tmux have to use an extra-wurst?

In T8156#216401, @ikloecker wrote:

I'm not sure if we should consider env DISPLAY=invalid pinentry-qt a valid test.

[...]

So, I guess, @ametzler1's suggestion to remove the check for isX11SessionType is the correct solution. DISPLAY=invalid would still not work, but I think that's acceptable.

Great spotting! This was it. Quite embarrassing that I've looked at this code so many time yet it didn't cross my mind to double check arguments order.

@jpalus You are right.

computed by ssh_signature_encoder_rsa, including additional 0, reach:

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

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

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

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

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