Subject: Re: [ANNOUNCE] linux-stable security tree
References: <570BE4A5.20200@oracle.com> <20160411184148.GA23140@kroah.com>
 <570BF3DD.2060900@oracle.com> <20160411200904.GB24106@kroah.com>
 <570C0B39.1090408@oracle.com> <20160411211708.GB32758@1wt.eu>
 <570C29C0.9080206@oracle.com> <20160412062237.GA507@1wt.eu>
 <20160412063508.GA21417@kroah.com> <20160412081131.GB537@1wt.eu>
To: Willy Tarreau <w@1wt.eu>, Greg KH <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sasha.levin@oracle.com>, LKML <linux-kernel@vger.kernel.org>,
        stable <stable@vger.kernel.org>, lwn@lwn.net
From: Eddie Chapman <eddie@ehuk.net>
Reply-To: Eddie Chapman <eddie@ehuk.net>
Message-ID: <570CEA99.1020101@ehuk.net>
Date: Tue, 12 Apr 2016 13:31:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20160412081131.GB537@1wt.eu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2108
Lines: 39

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