linux-kernel - Re: [ANNOUNCE] linux-stable security tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160411184148.GA23140@kroah.com>
Date:	Mon, 11 Apr 2016 11:41:48 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	stable <stable@...r.kernel.org>, lwn@....net
Subject: Re: [ANNOUNCE] linux-stable security tree

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