openssh unix dev - Oct 2023 - Open SSH End-of-Life Schedule?

Q: What type of changes, "incompatibilities" do you see, or
experience, that would require something like that?

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.

 
> On 13 Oct 2023, at 19:10, Jeremy Guthrie <Jeremy.Guthrie at 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://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 <djm at mindrot.org>
wrote:
>> 
>> EXTERNAL EMAIL
>> 
>> On Tue, 10 Oct 2023, Jeremy Guthrie wrote:
>> 
>>> 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://urldefense.com/v3/__https://endoflife.date/__;!!HUqgN_M!p3EDk0gRs5gn7cKVhvaGi0EPp_iDoEN1rx4RZWA-SlQIvZKlOTjUH34xZLDNKT2lbH-sL9QA3qC03-4$
>>> Example of OpenSSL: 
https://urldefense.com/v3/__https://endoflife.date/openssl__;!!HUqgN_M!p3EDk0gRs5gn7cKVhvaGi0EPp_iDoEN1rx4RZWA-SlQIvZKlOTjUH34xZLDNKT2lbH-sL9QA-tunzHw$
>> 
>> No. We don't ship a library, so the situation is different.
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> On Oct 13, 2023, at 2:55?PM, hvjunk <hvjunk at 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.

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.Guthrie at
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/ansible-core__;!!HUqgN_M!rCGGnCORBI7CVVWQOSh_jkSqXsP6Y2z3efMdI9pVehBkESh6qzfOCZ4uGlVf0jNtVhV2wg9j1fpbtjvM$
>>
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$
>> "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."
>> 
>