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

[Antoine Beaupré <anarcat@orangeseeds.org>]

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.

a.

-- 
You Are What You Is
                        - Frank Zappa