Ubuntu 18.04's Heavily Patched Kernel Opens Door To Lockdown Bypass, Breaks Secure Boot

[skeevy420]

LTS does not mean jackshit. I bet there's a lot more SUSE people on the 5.3.x branch than people doing the kernel.org 3.6.x series.

I really hope you mean 5.6.x series. But there's probably even more people on the 5.4.x branch since that's currently both the kernel.org LTS kernel and Ubuntu's LTS kernel.

You're right. I don't even know how to acronym jackshit into LTS.

[skeevy420]

There is nothing to worry about, openSUSE uses the kernel that they deem appropriate to use and have engineers who know how a kernel works. Among other things, Leap uses the same kernel of SUSE that is intended for the corporate world, therefore in practice much safer than others.
In this case it seems to be a Canonical error, it can happen, as it can also happen with the vanilla kernel.

And we say the same things about Ubuntu and their Linux engineers and yet here we are. It really doesn't matter what distribution since all it takes is one person missing one thing or setting up one patch wrong. Starting with an EOL'd kernel means that they have that much more stuff to consider, backport, and/or keep up with.

FWIW, I feel the same way about Red Hat and CentOS currently using the EOL'd 4.18 when 4.19 is the current LTS kernel and still supported upstream.

Half my issue is crap going wrong with all the stuff extra to consider, the other half is about the distributions working closer with upstream so there aren't as many Franken-kernels.

EDIT: I had the RH/Cent and upstream kernel versions swapped before the edit.

[Slartifartblast]

FWIW, I feel the same way about Red Hat and CentOS currently using the EOL'd 4.19 when 4.18 is the current LTS kernel and still supported upstream.

4.19 is an LTS Kernel.

https://www.kernel.org/

[Charlie68]

And we say the same things about Ubuntu and their Linux engineers and yet here we are. It really doesn't matter what distribution since all it takes is one person missing one thing or setting up one patch wrong. Starting with an EOL'd kernel means that they have that much more stuff to consider, backport, and/or keep up with.

FWIW, I feel the same way about Red Hat and CentOS currently using the EOL'd 4.19 when 4.18 is the current LTS kernel and still supported upstream.

Half my issue is crap going wrong with all the stuff extra to consider, the other half is about the distributions working closer with upstream so there aren't as many Franken-kernels.

Human error is always possible, even the vanilla kernel has happened to have had security problems in the past, we are human beings and humans can make mistakes, the important thing is that if discovered they are resolved.

[Azrael5]

Human error is always possible, even the vanilla kernel has happened to have had security problems in the past, we are human beings and humans can make mistakes, the important thing is that if discovered they are resolved.

I understand the error in the nature of human beings... we are not technical perfect which is different form goodness and evil in free will. What I don't understand is the aware delay to fix the severe issue, that is the mistake to persevere in the mistake.

[skeevy420]

4.19 is an LTS Kernel.

https://www.kernel.org/

Dyslexia in memory dammit

Swap the versions around and my statement is correct

[skeevy420]

Human error is always possible, even the vanilla kernel has happened to have had security problems in the past, we are human beings and humans can make mistakes, the important thing is that if discovered they are resolved.

But these distributions are intentionally making it harder on themselves and that directly increases the likelihood of human error. Instead of a bunch of eyes on the problem, everyone is looking at different places.

[Leinad]

Why do they even use kernel 4.15? The previous version (4.14) would have been an upstream LTS release.

4.15 had much better AMD drivers than 4.14: https://www.phoronix.com/scan.php?pa...PU-DC-Accepted

[Leinad]

There is nothing to worry about, openSUSE uses the kernel that they deem appropriate to use and have engineers who know how a kernel works. Among other things, Leap uses the same kernel of SUSE that is intended for the corporate world, therefore in practice much safer than others.
In this case it seems to be a Canonical error, it can happen, as it can also happen with the vanilla kernel.

No, Leap does not use the same kernel. Leap uses same kernel sources, but more features are enabled on Leap than on SLE.

[elatllat]

But these distributions are intentionally making it harder on themselves and that directly increases the likelihood of human error. Instead of a bunch of eyes on the problem, everyone is looking at different places.

This.