Re: [ANNOUNCE] linux-stable security tree

[Willy Tarreau]

Hi Eddie,

On Tue, Apr 12, 2016 at 01:31:21PM +0100, Eddie Chapman wrote:
> None-the-less, I applaud and thank Sasha for this new effort, and I
> personally will find it very useful.  Yes, the lines between bug fix and
> security fix are very blurred, and so this tree won't have every "security"
> fix. But I believe and trust it *will* at least contain fixes for bugs that
> have the most severe security impact.

It will only contain them if they are already in the respective stable trees,
which means that when I miss a fix (common), it won't appear there either.
At first I thought "oh cool, a repository of known things that must absolutely
be fixed, that will help me do my backports" and in the end I fear it will be
blindly used by end users who don't understand what they're missing but who
still believe they limit the risk of upgrades. Just this morning I saw a
report of a user saying that haproxy crashes is 2.6.24 kernel which is
"otherwise perfectly stable and achieves multi-years uptime"... Imagine
what such users will do when backporting fixes into they multi-thousands-bugs
kernel!

> Where I will find this very useful is in having a "place" where I can see
> what are probably the most important security fixes applicable to the stable
> trees I am interested in.  Because if I may offer one criticism of the
> kernel stable trees in general, it is that it is very hard to find and
> identify fixes for known security vulnerabilities. Whenever I want to update
> the kernel in one of my projects, I find myself having to hunt around a lot
> for information, stringing together bits from bug reports, mailing lists,
> git commits, to track down whether or not a particular vulnerability is
> fixed in a stable tree.  Not always, sometimes it is very clear that a
> particular fix in a particular stable release fixes a known vulnerability,
> especially with commits e.g. referencing CVEs in the header or commit
> message. At other times there might be absolutely nothing in the fix to
> indicate this fixes a known vulnerability.

I agree with this and it's not inherent to the stable trees but to the fact
that vulnerability IDs are assigned via a parallel process and often after
a fix gets merged, so the link between the commit and the CVE ID is easily
lost. Yes a central repo of known bugs by kernel branch and the commits
which fix them would be immensely useful including to the maintainers, but
it's a huge work and I hardly see who would work on such a thing. Note that
it doesn't necessarily need to focus on security only. Any painful bug should
be referenced as present first, then fixed with the relevant commit IDs once
the backports are merged. The "fixes" tag in upstream commits is already a
step forward, but in any case we'd need post-documentation since it regularly
happens that a bug happens to be accidently fixed by some later changes.

Regards,
Willy