From: Dragan Simic Date: Tue, 23 Jul 2024 16:36:23 GMT Subject: Re: Request to Update OpenSSH Version in Git due to Security Vulnerabilities (CVE-2006-5051, CVE-2024-6387 Message-ID: <9b075f5b19bc6e31a0f4a829dbc623e8@manjaro.org> In-Reply-To: Hello Johannes, On 2024-07-22 11:38, Johannes Schindelin wrote: > On Wed, 10 Jul 2024, 'Dragan Simic' via Git Security wrote: > >> On 2024-07-10 19:10, Junio C Hamano wrote: >> > Johannes Schindelin writes: >> > >> > > The crucial part is the `sshd` part. Git for Windows does distribute the >> > > `sshd.exe` binary, but it is in no way used by default, nor is there >> > > support how to set it up to run an SSH server. >> > > >> > > Git for Windows is therefore not affected by this vulnerability, and >> > > therefore it is not crucial to get a new version out as quickly as >> > > possible. See also my assessment at >> > > https://github.com/git-for-windows/git/issues/5031#issuecomment-2199722969 >> > >> > I think I've seen in the past another inquiry about vulnerability >> > in OpenSSH, which turned out to be irrelevant in the context of Git >> > for Windows for this exact reason (i.e. "sshd" is problematic but >> > "ssh" is OK). >> > >> > Would it make future confusion like this less likely if you stopped >> > shipping the sshd and ship only the ssh client? >> >> Not shipping sshd.exe would make sense regardless of the associated >> security >> issues, because it would prevent accidental enabling of SSH access. > > There is little accidental about starting `sshd` after generating a > valid > host key. Well, I don't know what and how Git for Windows does regarding the host key generation, so the possibility of accidental starting the shipped sshd.exe may actually be quite low. > Having said that, `sshd` is not required to run Git, therefore it > should > not be distributed with Git for Windows. This PR addresses that: > https://github.com/git-for-windows/build-extra/pull/571 Interestingly, that pull request shows that some people actually use(d) the shipped sshd.exe, which just shows that nearly every change will inevitably break somebody's workflow.