5.10 LTS Kernel: 2 or 6 years?
f.fainelli at gmail.com
Thu Feb 18 12:16:34 EST 2021
On 2/18/2021 3:31 AM, Willy Tarreau wrote:
> 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
> +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.
Well, let us say that the authors had a chance to review the backports
being applied but given the volume maybe they did and silence means
agreement, or maybe they did not get a chance to review those changes.
Let us say that the trust level of the offical stable kernels is just
the highest of all kernels that are out there?
> 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!
Yes, definitively not setting up for success.
More information about the linux-arm-kernel