linux-kernel - Re: 5.10 LTS Kernel: 2 or 6 years?

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: <20210218113107.GA12547@1wt.eu>
Date:   Thu, 18 Feb 2021 12:31:07 +0100
From:   Willy Tarreau <w@....eu>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Scott Branden <scott.branden@...adcom.com>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>
Subject: Re: 5.10 LTS Kernel: 2 or 6 years?

On Thu, Feb 18, 2021 at 08:43:48AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote:
> > Other difficulty with the LTS version is the frequency it is updated.

What a stange statement! So basically if fixes come in quickly so that
customers are not exposed too long to well-known issues, it's a difficulty ?
I guess by now every serious OS vendor provides at least weekly fixes, and
at an era where devices are all interconnected, it's really necessary
(unless of course you don't care about your customer's security).

> > We would not
> > pickup the changes that frequently to test.  A quarterly, bi-annually, or when a critical fix
> > is identified would be when we update and perform any meaningful testing when in maintainence.
> 
> How are you "identifying" these "critical fixes"?  We fix at least one
> known security issue a week, and probably multitudes of
> unknown-at-this-moment ones.  How are you determining when you need to
> send a new base kernel update off to your customers?  At such long
> intervals it feels like anyone using your kernel releases is woefully
> insecure.

+1! It seems like this dangerous practice will never end :-(

Let me explain a personal experience. When I took over 2.6.32 many years
ago, Greg asked me to adapt to the new maintenance process involving the
patch reviews. At first I feared that it would increase my amount of work.
And it did. But I also discovered how important these reviews were, because
I started to get lots of "don't take this one in this version" and more
importantly "if you merge this you'll need these ones as well". And very
quickly I discovered how bogus the branches I used to maintain before
had been, given the high feedback ratio!

So based on this experience, I can assure anyone doing cherry-picks in
their garage from LTS kernels that they're doing crap and that they must
not distribute these kernels to anyone because THESE KERNELS ARE DANGEROUS.
It's even very easy to introduce vulnerabilities by doing this!

The only set of fixes that can be trusted are the "official" stable
kernels, because they are the only ones that are approved by the patches
authors themselves. Adding more stuff on top of stable kernels is fine
(and done at your own risk), but randomly dropping stuff from stable
kernels just because you don't think you need that is totally non-sense
and must not be done anymore!

Willy