Re: [PATCH] Given a package allow to check in which releases security support has ended

[Guido Günther <agx@sigxcpu.org>]

Hi,
On Wed, Feb 17, 2016 at 01:39:41PM -0500, Antoine Beaupré wrote:
> On 2016-02-17 12:13:35, Guido Günther wrote:
> > When triaging LTS issues I always have to look up what we still support
> > and what not. Attached script simplifies this a bit:
> >
> >     $ bin/support-ended.py --lists /path/to/debian-security-support/ iceape
> >     Package unsupported in wheezy
> >     Package unsupported in squeeze
> >
> > Does this make sense? It would be great if we could later add this to
> > the scripts mangling data/CVE/list to add the <end-of-life> entries
> > automatically. What would be the right place for that?
> >
> > I didn't find a place in Debian where we canonically map release names
> > to release numbers (i.e. squeeze -> 6.x, jessie -> 7.x). I'm sure there
> > is such a thing so I'm happy about any pointers.
> 
> Good idea, couldn't this be integrated in find-work?

Either that one or in lts-cve-triage so we can mark them upfront when
triaging bugs.

Carnil pointed out that he does not just mark packages as <end-of-life>
but rather checks beforehand if the vulnerable code is present at all
and marks them as <not-affected> if not even if the package is
unsupported. This gives a lower bound on the affected versions. I wonder
if we should adopt the same practice to ease the work of the security
team a bit? At least in cases where it's rather simple to check. So for
packages unsupported in the LTS release

  <end-of-life>: not supported but vulnerability likely present
  <not-affected>: vulnerable code not present

Cheers,
 -- Guido