installer/portable: exclude sshd

[dscho]

The OpenSSH daemon (i.e. the server-side) is not actually something Git for Windows needs per se, nor wants to support. So let's stop shipping it.

[dscho]

/add relnote feature The server-side component of OpenSSH, which had been shipped with Git for Windows for historical reasons only, is now no longer distributed with it.

The workflow run was started

[bzanin-wdc]

I understand the logic for this change and in general I support it, but I should mention that Git for Windows shipping sshd has created the opportunity to work around some very thorny issues at $JOB.

In particular we sometimes encounter workflows where developers investigate CI failures on specific worker nodes where prototype hardware is attached for full-stack validation, discover tuning or logic issues, craft trial patches in situ, then wish to push their experimental changes back upstream to a feature branch. They are blocked in this desire for convenience by worker nodes lacking their GPG and SSH keys for signing commits and pushing, respectively; but being able to spin up a one-shot SSH daemon process to briefly support tunneling their local ssh-agent and gpg-agent sockets to the node has served them well. Once Git for Windows stops packaging sshd this convenience will disappear.

I still support this change, I just wanted to call out that its impact will be non-zero in at least one shop.

[dscho]

@bzanin-wdc I did suspect that there were users of sshd.exe out there (cf. Hyrum's law).

In your instance, would spinning up a git daemon work as well? After all, the IP seems to be accessible, the ports open, and this scenario is precisely what git daemon was designed for. The only difference vs sshd is that is unauthenticated.

[bzanin-wdc]

In your instance, would spinning up a git daemon work as well? After all, the IP seems to be accessible, the ports open, and this scenario is precisely what git daemon was designed for. The only difference vs sshd is that is unauthenticated.

The lack of authentication would make this option a non-starter, but otherwise it looks like a good match, conceptually. The hypothetical workflow could be that the developer works on the lab machine for a bit, commits their changes, spins up git-daemon, pulls their changes to their personal work machine, amends the commit to GPG-sign it, then pushes it back upstream to the central repo connected to the CI/CD pipeline.

With the authentication step missing and therefore git daemon being off the table, most of that workflow could still be performed. The dev could sub out the git daemon step for generating a git bundle, transferring it to their local workstation, then pulling from it, amending/signing the commit, and pushing it back upstream.

It's a lot of steps but it might do the trick.

Thank you for the pointer.

[dscho]

The lack of authentication would make this option a non-starter

You could also go for the opposite direction: starting up a (regular, Win32) OpenSSH server on the developer's machine, add a private key on the CI machine and add its public key to the server's authorized_keys, then push rather than pull.

[hidromagnetismo]

When I install "Git for Windows SDK v1.0.8" it installs sshd.exe version 9.8p1 (OpenSSH), does this binary have the vulnerability?

Translated from Spanish to English.
I find it unlikely that sshd.exe will run by itself. I would be happy if the installation GUI would ask me to select the most useful binaries like, rsync.exe or tmux.exe (too bad gnu screen is not around), and of course sshd.exe (which would be disabled by default). Another option is that it comes with pacman.exe and then one installs everything else. You would have the benefit of installing less than 100MB as opposed to the 1GB+ that the SDK requires.

[dscho]

sshd.exe version 9.8p1 (OpenSSH), does this binary have the vulnerability?

See git-for-windows/git#5094 (comment)