Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755062AbcDKSlv (ORCPT ); Mon, 11 Apr 2016 14:41:51 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58089 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752807AbcDKSlt (ORCPT ); Mon, 11 Apr 2016 14:41:49 -0400 Date: Mon, 11 Apr 2016 11:41:48 -0700 From: Greg KH To: Sasha Levin Cc: LKML , stable , lwn@lwn.net Subject: Re: [ANNOUNCE] linux-stable security tree Message-ID: <20160411184148.GA23140@kroah.com> References: <570BE4A5.20200@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570BE4A5.20200@oracle.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1932 Lines: 49 On Mon, Apr 11, 2016 at 01:53:41PM -0400, Sasha Levin wrote: > Hi all, > > > I'd like to announce the linux-stable security tree project. The purpose > is to create a derivative tree from the regular stable tree that would > contain only commits that fix security vulnerabilities. And how are you going to define "security vulnerabilities"? Also, what kernel branches are you going to do this for, and for how long? > Quite a few users of the stable trees pointed out that on complex deployments, > where validation is non-trivial, there is little incentive to follow the > stable tree after the product has been deployed to production. There is no > interest in "random" kernel fixes and the only requirements are to keep up > with security vulnerabilities. "random" is in the eye of the beholder :) Everyone's definition of that is different, I think you will find that it's best to just do the full tree, or pick and choose what you want from the tree based on your own needs, instead of trying to judge what those needs are. > Given this, a few projects preferred to delay important kernel updates, and > a few even stopped updating the tree altogether, exposing them to critical > vulnerabilities. What projects are those? Is it really that hard to take the current stable trees for these projects? Why is this tree going to somehow be easier? > This project provides an easy way to receive only important security commits, > which are usually only a few in each release, and makes it easy to incorporate > them into existing projects. Define "important". Now go and look at the tty bug we fixed that people only realized was "important" 1 1/2 years later and explain if you would, or would not have, taken that patch in this tree. Good luck with this, personally, I think projects should just take the stable tree as really, it's not that much churn at all, given the % of the mainline tree. thanks, greg k-h