LTS is a very good and established concept/naming - and I like it a lot and
if we could adopt recommendations for that approach as Piotr suggests and
suggest it to the projects that would be cool.
But I think it applies to a subset of projects (mainly foundational
libraries).
LTS is good for "OS" and "popular libraries" that upstream dependencies
depend on.
But for the projects that are not really libraries but "end products" (say
Airflow, Superset, Dolphin Scheduler etc. etc. ) - LTS is not something
that the project has and the concept is a bit "alien". They usually have 1
or few "branches" that are maintained and security fixes are applied, and
there is no real "LTS" concept. Simply the versions that are maintained
have either regular fixes or only security fixes applied usually, and there
are EOL versions that receive no fixes any more. This is because the LTS
concept is really when other software depends on it.
So here I'd say we should talk about some classification for maintenance
("ACTIVELY DEVELOPED", "BUGFIX ONLY", "SECURITY ONLY", "EOL" ?) release
"branches" or smth similar.
Note - those are concept names only - I have no good naming for the first
three, EOL seems to be established.
Example: in Airflow we have:
- 3.* ACTIVELY DEVELOPED (not released yet)
- 2.* BUGFIX ONLY (including security).
- 1.10.* EOL (not maintained for 3 years already - not even security fixes
applied)
In about 5 months those will change:
- 3.* ACTIVELY DEVELOPED (released yet)
- 2.* BUGFIX ONLY (including security).
- 1.10.* EOL (not maintained for 3 years already - not even security fixes
applied)
At some point in time (still to be decided) the 2.* branch will turn into
another state where likely only security fixes will be applied (we will
still have to decide for how long, how to name that branch etc.)
- 3.* ACTIVELY DEVELOPED (released yet)
- 2.* SECURITY ONLY
- 1.10.* EOL (not maintained for 3 years already - not even security fixes
applied)
Eventually 2.* branch will turn into EOL (but when and how we do not know
yet and I guess in the future CRA and other regulations will determine how
long a released software should receive fixes until it will turn into EOL
state - but that very much depends on the standards that will be accepted
for that).
I think it's quite important to also get a good consistent naming for that
pattern for end-products and have a good naming and recommendation for
ACTIVELY_DEVELOPED / BUGFIX ONLY/ SECURITY ONLY / EOL "classification" of
branches.
J.
On Wed, Oct 16, 2024 at 9:52 AM Gilles Sadowski <gillese...@gmail.com>
wrote:
> Hello.
>
> Le mer. 16 oct. 2024 à 08:22, Piotr P. Karwasz
> <piotr.karw...@gmail.com> a écrit :
> >
> > Hi Christopher,
> >
> > On Thu, 10 Oct 2024 at 18:14, Christopher Schultz
> > <ch...@christopherschultz.net> wrote:
> > > • Canned responses to issues (?)
> > > • security.txt
> > > • Dedicated security team (secur...@project.apache.org)
> > > ◦ Reduce security@ and private@ where appropriate/possible
> > > • Create and document detailed incident response
> > > ◦ Including key contacts and contact information
> > > • Disable inherently insecure features
> > > • Documented release process
> > > • Documented security / threat model(s)
> > > • Reproducible builds
> > > • Automated release process
> > > • SBOMs
> > > • Harden CI workflows (?)
> >
> > Nice list, might I add another item we recently briefly discussed on
> Slack[2]:
> >
> > * introduce minor branches with long term security support (and nothing
> else).
> >
> > Since making any upgrade of a dependency can always break something
> > (e.g. the bugs or implementation specific behavior you are relying
> > on), many companies don't upgrade until it is necessary.
> > This is of course a risk, since those missed upgrades will hit them
> > all at once, when a CVE is published. The problem can be solved with
> > LTS branches that only receive critical and security updates, as
> > advocated by OpenJDK in JEP[1].
> >
> > Right now users decide themselves, which version of a library they
> > will be using for the next 5 years or so: it's usually the first
> > version without any known vulnerabilities. As an example, downloads of
> > Log4j Core 2.17.x amount to around 40% of the total downloads of Log4j
> > Core. Of course if a vulnerability were to be discovered today, there
> > would be no 2.17.3 release, but only a 2.24.2 release.
> >
> > Offering LTS branches with extended security support is not a choice a
> > single project can make: a good LTS version must only use LTS versions
> > of its dependencies. Since we depend on Commons, such an initiative
> > should be ASF-wide.
>
> And "Commons" doesn't/can't make any LTS promise.
> Rather, it has always stated that only the latest release is supported.
> [The first question to someone reporting a bug in an older version is
> whether it exists in the latest release.]
>
> Regards,
> Gilles
>
> >
> > Piotr
> >
> > [1] https://openjdk.org/jeps/14
> > [2] https://the-asf.slack.com/archives/C4TQW0M5L/p1728204781631769
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
> For additional commands, e-mail:
> security-discuss-h...@community.apache.org
>
>
