Prerequisites
Steps to reproduce
I have thought some time about whether or not I should file the following issue as a bug or file it in another category. I finally came to the conclusion that not providing critical security patches is a serious bug (not in the software itself, but in the way of providing it), so here we go:
I have understood that Microsoft cannot support all versions of OpenSSH that are published here, and that the versions are therefore tagged "preview" or "beta". I am fine with that.
However, I would have expected that there is at least one binary release per upstream version of OpenSSH, and that these binary releases would be provided in a very timely manner (that is, less than a week after the upstream release).
But this is not the case. At the time of writing, the latest binary release is 10.0 from 9 months ago. Upstream has released 10.4 in the meantime. I have studied the release notes of all upstream versions between 10.1 and 10.4 and have seen that there were about 14 critical security fixes (besides several dozens of other bug fixes).
If I get this right, this would mean that critical security vulnerabilities are ignored in OpenSSH for Windows, and that critical patches are not provided for many months or (maybe in the future) even years.
I would like to get a statement from the developers regarding this problem. I may very well misunderstand something, and in this case I apologize and would like to be corrected. But if I am right, what actions do the developers recommend to cope with the problem?
I understand that it was probably very difficult to port OpenSSH from unixoid systems to Windows. However, now that the toolchain is established (obviously), I would expect that it's no more a very big problem to provide a new binary release soon after an upstream release.
Otherwise, OpenSSH for Windows won't be usable for us, because we cannot afford critical security vulnerabilities that are known and published since many months in our SSH servers.
Apart from that, I'd like to emphasize that I'm very grateful for the native Windows SSH daemon and for the hard work. In our tests, it works reliably, and now that sntrup is included, it is very close to being usable. The only thing that keeps us away from it is the problem explained above.
If we could finally use it, that would make life easier. Currently, we have quite some SSH daemons running in Cygwin on Windows servers, which is cumbersome.
Thanks for any comments in advance!
Expected behavior
A new binary release is published within a few days after a new upstream release, of course including at least all security fixes from the upstream version.
Actual behavior
New binary releases are published extremely rarely, putting every system that runs the Windows OpenSSH daemon at high risk, because fixes for critical security vulnerabilities that are published since many months are not provided.
Error details
Environment data
Name Value
---- -----
PSVersion 5.1.26100.8875
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.26100.8875
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Version
10.0.0.0
Visuals
No response
Prerequisites
Steps to reproduce
I have thought some time about whether or not I should file the following issue as a bug or file it in another category. I finally came to the conclusion that not providing critical security patches is a serious bug (not in the software itself, but in the way of providing it), so here we go:
I have understood that Microsoft cannot support all versions of OpenSSH that are published here, and that the versions are therefore tagged "preview" or "beta". I am fine with that.
However, I would have expected that there is at least one binary release per upstream version of OpenSSH, and that these binary releases would be provided in a very timely manner (that is, less than a week after the upstream release).
But this is not the case. At the time of writing, the latest binary release is 10.0 from 9 months ago. Upstream has released 10.4 in the meantime. I have studied the release notes of all upstream versions between 10.1 and 10.4 and have seen that there were about 14 critical security fixes (besides several dozens of other bug fixes).
If I get this right, this would mean that critical security vulnerabilities are ignored in OpenSSH for Windows, and that critical patches are not provided for many months or (maybe in the future) even years.
I would like to get a statement from the developers regarding this problem. I may very well misunderstand something, and in this case I apologize and would like to be corrected. But if I am right, what actions do the developers recommend to cope with the problem?
I understand that it was probably very difficult to port OpenSSH from unixoid systems to Windows. However, now that the toolchain is established (obviously), I would expect that it's no more a very big problem to provide a new binary release soon after an upstream release.
Otherwise, OpenSSH for Windows won't be usable for us, because we cannot afford critical security vulnerabilities that are known and published since many months in our SSH servers.
Apart from that, I'd like to emphasize that I'm very grateful for the native Windows SSH daemon and for the hard work. In our tests, it works reliably, and now that
sntrupis included, it is very close to being usable. The only thing that keeps us away from it is the problem explained above.If we could finally use it, that would make life easier. Currently, we have quite some SSH daemons running in Cygwin on Windows servers, which is cumbersome.
Thanks for any comments in advance!
Expected behavior
A new binary release is published within a few days after a new upstream release, of course including at least all security fixes from the upstream version.
Actual behavior
New binary releases are published extremely rarely, putting every system that runs the Windows OpenSSH daemon at high risk, because fixes for critical security vulnerabilities that are published since many months are not provided.
Error details
Environment data
Version
10.0.0.0
Visuals
No response