See the the commit for a description of the changes.

@MathiasMagnus This change is to support Win32-OpenSSH by gpg-agent emulation of ssh-agent; You can use gpg-agent emulation of ssh-agent when you use Win32-OpenSSH. That is, you can use GPG auth subkey for Win32-OpenSSH.

@gniibe Am I misunderstanding something? I thought that with this change one is able to connect from a Windows box to a Linux box and have GPG agent forwarding work. I am still hitting pretty much the same issue described here: https://github.com/PowerShell/Win32-OpenSSH/issues/1564
On my Windows endpoint I'm running gpg.exe version 2.4.0.49237 and in C:\Users\mate\AppData\Roaming\gnupg\gpg-agent.conf I have a single line enable-win32-openssh-support. Running gpg-connect-agent.exe reloadagent /bye I have a gpg-agent running. Get-Process gpg-agent shows that it's running. In my Windows env I have SSH_AUTH_SOCK set to \\.\pipe\openssh-ssh-agent and my Linux endpoint is configured in SSH config with

ForwardAgent yes
AddKeysToAgent yes
RemoteForward /run/user/1015/gnupg/S.gpg-agent C\:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra

As the remote end reports /run/user/1015/gnupg/S.gpg-agent that socket for agent-socket when issuing gpgconf --list-dirs and my local gpgconfg.exe --list-dirs reports C%3a\Users\mate\AppData\Local\gnupg\S.gpg-agent.extra where I transform %3a to \: manually. SSH authentication works perfectly, when connecting pinentry-qt pops up to unlock my key and when connecting to yet another machine, my SSH agent is forwarded again. However, gpg fails to use my agent. Issuing gpg --list-secret-keys --verbose prints the following to the console:

gpg --list-secret-keys --verbose
gpg: using pgp trust model
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: waiting for the agent to come up ... (5s)
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: waiting for the agent to come up ... (4s)
gpg: waiting for the agent to come up ... (3s)
gpg: waiting for the agent to come up ... (2s)
gpg: waiting for the agent to come up ... (1s)
gpg: can't connect to the agent: End of file

What is missing to tie the knot on both ends without having to resort to 3rd party tools like @rupor-github 's agent-gui? The remote gpg version is 2.2.19, is that the issue? Must that also be 2.3.9+?

I guess we need some gpgme support as well.

How with --status-fd passed to gpgtar we will get these progress lines:

Those "curated keyrings" and keyservers don't work together. The whole idea of automated but curated keyrings is dead end.

To fix this we also need to fix our key selection test (key-selection.scm) which is can't cope with all combinations. The tests are run with a faked time of 2004-01-01 on all subsets of this ordered list of keys

See also T4713

Let's first collect all keys, assign a priority, sort, and only then send them back to ssh.

On the mailing list I wrote down my test results for en- and decrypting files (1-10 GB) with GnuPG and Gpg4win/Kleopatra. The encryption always ran with compression. Kleopatra needed more than 11 minutes to encrypt a file that is 10 GB big. Today I tested the encryption again but this time I added

compress-level 0

to gpg.conf (I also tried to add bzip2-compress-level 0 and then only compress-algo uncompressed because Bernhard was suggesting that in the mailing list but it made no difference).

Great! But as mentioned I would like to have a setting in Kleo to explicitly disable compression, GPGME_ENCRYPT_NO_COMPRESS. But that is a different task.

I am very sure that this is resolved and we support that in Kleopatra.

Thought about this for a while and rephrased and thus repopened.
I think it would be good to remove or explain the sha1sum checksums in the announcements.
Whether they are replaced by something else, e.g. sha256sum is of lesser importance.

Shouldn't we remove the sha1sum then as well? Or add an explanation?

Nope - too long for checking and introduces line wraps. Those who are not able to check digital signatures are also not able to properly handle checksum verification. On some platforms you don't even have a sha256sum tool. And they need to verify the mails first anyway. Note that for internal purposes we use sha256sum for years.

Reported by https://social.tchncs.de/@duxsco@digitalcourage.social/109546865597565084

Somehow I was waiting for such a comment ;-) Sure you are right and we will fix the README eventually.

This is probably not the right place, but considering you're telling people *here* that they should not build in the source tree, your README and INSTALL files do tell the users to do exactly that.

Thanks all. It is a bug in Win32 OpenSSH. https://github.com/PowerShell/Win32-OpenSSH/issues/1953 it is already fixed. I think the issue will be resolved after the update is shipped. I could use ssh -T git@github.com as a workaround.

Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0

Pushed the change.

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.

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

I will push this change:

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

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

You should do it for all software ;-).

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

To be released tomorrow.

@raysatiro: Please re-open if you are able to give us a reproducer

Fixed. Shall we backport this to gnupg22 ?

Thanks. Commited to master.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.