[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

On Thu, Feb 05, 2015 at 09:38:11AM +0100, Paul van der Vlis wrote:
Op 05-02-15 om 00:54 schreef Holger Levsen:
and then finally, sometime later in 2014, security support for oldstable was
finally introduced for the first time.

There was always a year security support for oldstable (sometimes with
some remarks in te release notes for Mozilla products).

That's not actually true. Prior to potato, security supported ended pretty much immediately upon the next release. With potato the security team pointed out vulnerabilities that affected slink for a few months, but I don't recall that any packages were built. Potato was the first release I'm sure got packages after its successor was released, and I remember the security team trying to figure out how long to keep that up. https://lists.debian.org/debian-devel-announce/2002/11/msg00001.html Note the reference to having done so for a whole three months. :) I don't think it went a full year, and I don't think it was clearly communicated when the team finally threw in the towel. Woody was the first release, I think, that got a full year of security updates. So that's almost 10 years, but only 5 releases. And "full year" always was best effort, and there were some packages that just didn't make it. Communication of that has varied, sometimes it was clear and sometimes not.

What changed in 2014 was an attempt to support for more than one year. The process of actually building security updates has gotten a lot easier, which made support more practical; I think the current security team doesn't spend much time finding machines to build things, the way things were done 15 years ago--but it will always be a lot of work backporting pactches to code that upstream stopped supporting years earlier. At some point, security updates for old releases is more a fig leaf than reality: nobody puts as much effort into finding problems with obsolete code as current code, so only the really obvious problems will get fixed. And another reality is that even for the obvious problems if the fix is too hard it'll get kicked down the road and not get done before the end of LTS. (Not a criticism of the debian LTS team, more an observation of LTS for both commercial and free projects over the decades.)

Mike Stone

Reply to: