I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.

I pushed a similar fix last week: rE885a287a57cf060b4c
and gnupg has a hack to fix it for oler libgpg-error versions.

I meant bypass the gpgme engine and call gpgsm directly. Maybe using gpgme's spawn engine. But I am not sure whether this is really a good idea. If we can find a way to pass multiple filenames to gpgsm --server that would be better. But requires updates to gpgsm.

Only just noticed that this was added incompletely, it was added to the build system but not linked in.

Authentication succeed if I pressed enter after:PTY allocation request failed on channel 0

I try WinGPG 4.1.0, and I receive an error:
ssh git@github.com
PTY allocation request failed on channel 0

@werner Do I understand correctly that by "It might be easier to bypass the gpgsm and run gpgsm directly" you mean using gpgsm in server mode? Or what do you mean with "bypass gpgsm and run gpgsm" (which seems contradictory).

Something like this should fix the behavior:

diff --git a/src/argparse.c b/src/argparse.c
index ef0c161..403c4a7 100644
--- a/src/argparse.c
+++ b/src/argparse.c
@@ -3000,7 +3000,13 @@ show_help (opttable_t *opts, unsigned int nopts, unsigned int flags)
         writestrings (0, "Options:", "\n", NULL);
       for (i=0; i < nopts; i++ )
         {
-          s = map_fixed_string (_( opts[ordtbl[i]].description ));
+          if ((opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER)
+              && opts[ordtbl[i]].description
+              && !*opts[ordtbl[i]].description)
+            /* It's empty header.  */
+            s = opts[ordtbl[i]].description;
+          else
+            s = map_fixed_string (_( opts[ordtbl[i]].description ));
           if ( s && *s== '@' && !s[1] ) /* Hide this line.  */
             continue;
           if ( s && (opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER))

I will push this change:

commit e89d57a2cb10bd04d266165015f159be2ab48984
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   Wed Dec 21 10:52:24 2022 +0900

With 100 concurrently running gpgsm processes they all try to get the lock for the keyring. And they need to do this several times and often also for the same certificate (fetched from an external resource to complete the chain). Not good. It might be easier to bypass the gpgsm and run gpgsm directly instead of adding a feature to gpgsm to directly import from many files.

Sure, we could do this. Shouldn't make the ImportCertificatesCommand much more complex than it already is.

Reopening this as there still seem to be ways to run into a deadlock as was reported in RT#13361. While I still think this points to some issue in gpgsm, when Testing this I found the behavior of Kleopatra to be wrong.

Note that in-source-tree builds are broken - see T6313

Unfortunately this breaks in-source-tree builds - see T6313

You should do it for all software ;-).

Has been remedied. We should have noticed before the release but the heavy warnings you get only appear if the binary is downloaded from the internet.

This was an accident. Will be fixed ASAP.

Sorry, one more thing: I should use out of source builds for all gnupg software (libgpg-error, libksba, etc)? It's fine if so, just want to check what the policy is.

Ah, thanks! I didn't know this was unsupported. I'll change what we're doing.

You are building in the source tree - not a good idea. This should be supported but we don't test this. Please make your life easier and don't do build this way. We try to fix this for the next release.

Release done

Not working on this at the moment.

Finished for now. Not sure if there's much we can/should test ourselves. Maybe we should simply close it and open new tasks for the findings in the report of the next accessibility test.

To be released tomorrow.

Done. I verified that gpg4win still builds.