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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 12 Apr 2016 10:11:31 +0200
From:	Willy Tarreau <w@....eu>
To:	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

On Mon, Apr 11, 2016 at 11:35:08PM -0700, Greg KH wrote:
> On Tue, Apr 12, 2016 at 08:22:37AM +0200, Willy Tarreau wrote:
> > I think we may have more of an issue educating our users than an issue
> > with the code we distribute.
> 
> I think that's the issue here, combined with users that just don't want
> to upgrade as it's "hard" for them.  There's nothing we can do about
> making it easier than we already do, and really, taking 200 patches is
> just the same work for them to take 100 patches in a release, so I
> don't buy the "I only want a small subset of fixes" argument, as it
> doesn't make any sense.

I've already met people who used to estimate the need for each patch
individually. In the end they face many more problems in production
than any other user just because they drop the important ones or those
that enable certain "security" fixes to work reliably. Most often it's
a way for them to secure their job because nobody else can do this work
around them. When they leave the team, their boss generally decides to
go to regular distros with their simple update process in the end.

> So I worry that this tree will give people a _false_ sense of security,
> thinking that they have properly covered the needed fixes when really,
> there are lots of fixes they didn't even know they needed that got
> applied to the "normal" stable tree for issues they will hit.

Also the stable tree gets fixed thanks to feedback from users. When we
do something wrong it doesn't last long.

> Also, people need to stop being afraid of the large numbers of stable
> patches, and compare it to the overall % of changes, and realize that
> what we take in stable releases is really a trivially small number of
> the overall changes made to the kernel.

Yep. As a rule of thumb, I'd rather recommend people who fear updates to
always stay late by 2-3 versions and monitor the more recent changelogs
for possible fixes for previous versions. That might possibly make them
more comfortable. It's not a good practice but it's already better than
not applying the required fixes at all.

And let me restate it, most of us are our own users. We *are* careful.
My company ships load balancers which achieve multi-year uptimes (when
people don't reboot to apply fixes). We don't want to mess up with a
faulty update there. Ben gets his work distributed to all debian users
and certainly doesn't want to take risks either.

Willy