On Thu, Feb 18, 2016 at 09:35:14AM -0500, Antoine Beaupré wrote: > On 2016-02-18 02:26:28, Guido Günther wrote: > > 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 > > The problem here is that LTS is so old that it is sometimes very > difficult to figure out if a vulnerability is present. Upstream and the > CVE material most likely do *not* even *know* if older versions are > vulnerable... > > So it's great to check, but sometimes it takes a long time, and I am not > sure it is worth spending that time on a unsupported package. So i think > it should rather be: > > <end-of-life>: not supported but vulnerability possibly present > <not-affected>: vulnerable code not present > > ie. on unsupported packages, we *can* mark an issue non-affected if we > have reasons to believe it is not, but if it's too complicated to check, > end-of-life is also fine, and does *not* mean there is necessarily a > vulnerability.
*possibly* is a better word than *likely* in this case, I agree. I'd suggest that we then document if we tried to pin down the vulnerability in the commit message. Cheers, -- Guido
