Open SSH End-of-Life Schedule?
Jeremy Guthrie
Example of OpenSSL: https://endoflife.date/openssl
--
Jeremy Guthrie
Sr Technical Architect - DevOps, Automation & Orchestration
5525 Nobel Dr Suite 200 | Fitchburg, WI 53711
Time Zone: US-Central
Phone: 608.298.1061
ECC: 888.793.2480 or 608.288.4000
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Damien Miller
> Is there any kind of published end-of-life schedule/expectations the OpenSSH community maintains that could be reflected on a site like of https://endoflife.date/
> Example of OpenSSL: https://endoflife.date/openssl
Jeremy Guthrie
https://endoflife.date/ansible-core
https://endoflife.date/tomcat
https://endoflife.date/postgresql
Example PostgreSQL Versioning policy:
https://www.postgresql.org/support/versioning/
"The PostgreSQL Global Development Group supports a major version for 5 years after its initial release. After its five year anniversary, a major version will have one last minor release containing any fixes and will be considered end-of-life (EOL) and no longer supported."
> On Oct 12, 2023, at 10:53 PM, Damien Miller <d...@mindrot.org> wrote:
>
> EXTERNAL EMAIL
> On Tue, 10 Oct 2023, Jeremy Guthrie wrote:
>
>> Example of OpenSSL: https://urldefense.com/v3/__https://endoflife.date/openssl__;!!HUqgN_M!p3EDk0gRs5gn7cKVhvaGi0EPp_iDoEN1rx4RZWA-SlQIvZKlOTjUH34xZLDNKT2lbH-sL9QA-tunzHw$
hvjunk
Tomcat: i't s a "platform" where newer technologies (ie. JDK version N+3) could introduce unexpected problems for business apps that runs on that platform to have security for a period.
Postgresql: as new features (ie. logical replication, and partitioning) requires base fileformat type changes and some wire protocol changes, there you'd want some stability for businesses to not backup-restore every couple of months.
Ansibe-core: yeah THAT is a fun one, having gotten bitten a couple of times over the years with older playbooks/roles not working on newer Python etc. Yes, I want/need indications on how long and which systems I'll have to redo and which I should not upgrade to keep the lights on.
OpenSSL/GnuTLS/LibreSSL: as newer portocols are introduces, and old protocols shown to be weak etc., you will have incompatibilities with applications with "major" version changes, and thus you want the minor versions to be running as long as possible with security patches when required, but at least the apps that (dynamically?) link to it will continue working.
OpenSSH: well... the only "incompatibilities" I've encountered, was when I needed to connect to older environments with (suspect) versions, when the newer OpenSSH already "deprecated by default" the problematic algorithms, otherwise I'm more in need of the versions with the security patches done right.
What I guess the OP "wants" is to say that version 9.5 will be supported for the next 3-5 years, and all the security patches be backported from versions 11,12,13,14,15 to 9.5.3-patch1234 etc. Since OpenSSH/etc. haven't changed the wire protocol in like 20odd years, I don't personally see a reason to require such, given the RFC standards for the protocol, given the number of competitors out there.
That said,perhaps the OpenSSH devs could state something like this to clear the "EOL" problem easily: the latest version will be the version we'll patch for security, any version before that we deemed EOL and won't support and ask you to first upgrade and test before making the bug submission.
Damien Miller
> Sorry, I should have been more clear. Just wondering in general if there is a policy, not as any kind of library. Below are more examples from that website of tools, servers and services. It’s possible there still isn’t a timeframe but wondering about general end-of-life expectations even if there have been only cursory discussions.
>
> https://endoflife.date/ansible-core
> https://endoflife.date/tomcat
> https://endoflife.date/postgresql
>
> Example PostgreSQL Versioning policy:
> https://www.postgresql.org/support/versioning/
> "The PostgreSQL Global Development Group supports a major version for 5 years after its initial release. After its five year anniversary, a major version will have one last minor release containing any fixes and will be considered end-of-life (EOL) and no longer supported."
We don't do major releases or minor versions, and we don't offer support
for any version*. We just fix bugs, add requested features and note
incompatibilities (almost always minor) that arise as we go.
Every now and then we'll make a change that causes some incompatibility,
e.g. killing ssh1 or deprecating weak crypto. We tend to announce these
years in advance to give people a chance to act.
* I mean, you can report a bug in any version and we'll look it it and try
to fix it if it is still present, but there's no LTS-like version where
we collect these bugfixes.
Jeremy Guthrie
>
> What I guess the OP "wants" is to say that version 9.5 will be supported for the next 3-5 years, and all the security patches be backported from versions 11,12,13,14,15 to 9.5.3-patch1234 etc. Since OpenSSH/etc. haven't changed the wire protocol in like 20odd years, I don't personally see a reason to require such, given the RFC standards for the protocol, given the number of competitors out there.
>
> That said,perhaps the OpenSSH devs could state something like this to clear the "EOL" problem easily: the latest version will be the version we'll patch for security, any version before that we deemed EOL and won't support and ask you to first upgrade and test before making the bug submission.
>
Swag Example: We provide fixes only for the latest releases of the last two major versions. e.g. 8.X, and 9.X. Once 10.X, comes out, we stop supporting 8.X, etc… I am not asking for a year commit, just trying to understand what the community feels like would be a good level of backward porting of fixes until some EOL date. It is okay if people do not have an answer, just wanted to see if this had been discussed before.
Those other examples I had below (sorry about the URL defense links), were just examples of what others have done to manage technical debt. They were not meant to be 1-to-1s, just ideas.
>
>
>> On 13 Oct 2023, at 19:10, Jeremy Guthrie <Jeremy....@cdw.com> wrote:
>>
>> Sorry, I should have been more clear. Just wondering in general if there is a policy, not as any kind of library. Below are more examples from that website of tools, servers and services. It’s possible there still isn’t a timeframe but wondering about general end-of-life expectations even if there have been only cursory discussions.
>>
>> https://urldefense.com/v3/__https://endoflife.date/tomcat__;!!HUqgN_M!rCGGnCORBI7CVVWQOSh_jkSqXsP6Y2z3efMdI9pVehBkESh6qzfOCZ4uGlVf0jNtVhV2wg9j1WK8PiiM$
>> https://urldefense.com/v3/__https://endoflife.date/postgresql__;!!HUqgN_M!rCGGnCORBI7CVVWQOSh_jkSqXsP6Y2z3efMdI9pVehBkESh6qzfOCZ4uGlVf0jNtVhV2wg9j1T3JTsIT$
>>
>> Example PostgreSQL Versioning policy:
>> https://urldefense.com/v3/__https://www.postgresql.org/support/versioning/__;!!HUqgN_M!rCGGnCORBI7CVVWQOSh_jkSqXsP6Y2z3efMdI9pVehBkESh6qzfOCZ4uGlVf0jNtVhV2wg9j1b7EXoJJ$
>>
>
Stuart Henderson
> > On Oct 13, 2023, at 2:55 PM, hvjunk <hvj...@gmail.com> wrote:
> >
> > What I guess the OP "wants" is to say that version 9.5 will be supported for the next 3-5 years, and all the security patches be backported from versions 11,12,13,14,15 to 9.5.3-patch1234 etc. Since OpenSSH/etc. haven't changed the wire protocol in like 20odd years, I don't personally see a reason to require such, given the RFC standards for the protocol, given the number of competitors out there.
> >
> > That said,perhaps the OpenSSH devs could state something like this to clear the "EOL" problem easily: the latest version will be the version we'll patch for security, any version before that we deemed EOL and won't support and ask you to first upgrade and test before making the bug submission.
> >
>
> Yes, I would say above is the ballpark I was hoping to get clarification on. In the end if a security bug came out, having a clear EOL policy lets you clearly tell your user-base when to expect versions will be retired and no longer taken care of. The longer the tail on software fixes the more effort it will take and technical debt you’re maintaining.
>
> Swag Example: We provide fixes only for the latest releases of the last two major versions. e.g. 8.X, and 9.X. Once 10.X, comes out, we stop supporting 8.X, etc… I am not asking for a year commit, just trying to understand what the community feels like would be a good level of backward porting of fixes until some EOL date. It is okay if people do not have an answer, just wanted to see if this had been discussed before.
That sort of policy is useful for software which updates multiple
branches in parallel, so you know when to switch to a newer "major
version", but not really where there's one main branch from which
releases are made and fixes are generally distributed by releasing
a new version (as is the case with OpenSSH).
Downstream distributors of OpenSSH are free to (and often do)
make their own backported patches for old versions, but that's
something which they're responsible for themselves.