Hi Gilles, On Wed, 16 Oct 2024 at 13:47, Gilles Sadowski <gillese...@gmail.com> wrote: > Who is going to take the responsibility to impose to someone else > (probably) that, some "x" years from now, some (expectedly outdated) > code base _must_ be released, with some CVE fixed, but otherwise > containing known bugs that were fixed in the intervening releases?
I don't mean to impose to any project to create "SECURITY ONLY" branches, but such branches do not seem to bring a lot of additional work (there are not a lot of vulnerabilities). Since _de facto_ some users will keep the same version of a dependency for years, why not make the ecosystem more secure and let them use a "SECURITY ONLY" branch with "SECURITY ONLY" dependencies? After a couple of years a "SECURITY ONLY" branch can reach "END OF LIFE" or reach what Jetty calls "End of Community Support"[1]: security fixes will be guaranteed for everybody as long as some commercial entities pay a large enough group of maintainers to backport security patches[3]. This is also the model adopted by the Extended LTS model in Debian. [1] https://github.com/jetty/jetty.project/issues/7958 [2] https://wiki.debian.org/LTS/Extended [3] I believe such a model is compatible with the Apache governance, since _vetos_ on a backported patch should also apply to the original. > "Commons" has been following a policy to make it easy and (hopefully) > harmless to upgrade to "minor" releases. Log4j has the same policy, although it doesn't always work out for everybody. There is also a psychological barrier for "minor" releases. Some users explained to me that they prefer Logback over Log4j Core, since the former keeps supporting older branches (like 1.2.x), while Log4j drops support for a minor branch once the next is published. Logback is not semantically versioned, so the 1.2.x branch contains new features and can even contain breaking changes, but it looks like a "safer" choice. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
