[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <570CEA99.1020101@ehuk.net>
Date: Tue, 12 Apr 2016 13:31:21 +0100
From: Eddie Chapman <eddie@...k.net>
To: Willy Tarreau <w@....eu>, Greg KH <gregkh@...uxfoundation.org>
Cc: Sasha Levin <sasha.levin@...cle.com>,
LKML <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>, lwn@....net
Subject: Re: [ANNOUNCE] linux-stable security tree
I'd like to add my 2c here as a mere user of many of the stable trees
for many years in my projects.
The stable trees are excellent. The quality of the people selecting
patches and the selection process is excellent. I've rarely been on the
bad end of a regression. I've always used stable kernels in virtually
all my own projects, as well as many clients' projects.
I agree with a lot of what Greg and Willy have said here. There are
plenty of examples of quite serious, non-security related (yes I know
defining security/non-security is problematic) bugs being fixed in
stable releases. IMO you deserve everything you get if you only applied
the fixes in Sasha's new tree and ignored the stable releases completely.
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.
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.
So anything which improves visibility, which this certainly does, is a
good thing in my opinion.
Eddie
Powered by blists - more mailing lists