MX Linux Forum

About once a week, sometimes less than that, kernel.org releases new kernel versions with security fixes.
Ubuntu updates their kernels about every two weeks.
Debian updates their kernels about every six weeks.
Why is Debian so slow?
Would it even be smart to use Debian for any type of multi user internet facing server and risk not getting kernel updates for 2 months?
Does the kernel version generally make much difference for that type of use?

What did debian say when you asked them?

BV206 wrote: Sun Apr 14, 2024 11:58 am About once a week, sometimes less than that, kernel.org releases new kernel versions with security fixes.
Ubuntu updates their kernels about every two weeks.
Debian updates their kernels about every six weeks.
Why is Debian so slow?
Would it even be smart to use Debian for any type of multi user internet facing server and risk not getting kernel updates for 2 months?
Does the kernel version generally make much difference for that type of use?

I believe your misinformed. Debian pushes critical / security updates out quite quickly, in many cases daily. And then much slower on non critical updates.( Taking time to test and evaluate.)

Have a look at this page:

https://www.debian.org/security/

CharlesV wrote: Sun Apr 14, 2024 12:18 pm I believe your misinformed.

Probably. I have no software or systems development experience at all.

The Debian security page has 12 "linux security update" since Jan 2023. Most of those start with "Several vulnerabilities have been discovered in the Linux kernel..." It seems to me like there should be more unless they are fixed by other packages besides "linux".

There are 67 listed in 2024

CharlesV wrote: Sun Apr 14, 2024 12:18 pm ... Debian pushes critical / security updates out quite quickly, in many cases daily. And then much slower on non critical updates.( Taking time to test and evaluate.)

Have a look at this page:
https://www.debian.org/security/

Right, and it is pretty stupid to have an update at each kernel.org update, and for each current kernel versions, and for each platforms (amd64, x32,etc). (excepted for particular uses).
https://www.kernel.org/

CharlesV wrote: Sun Apr 14, 2024 1:42 pm There are 67 listed in 2024

Are you saying that everything listed at https://www.debian.org/security is a linux kernel update?

We get security updates within the kernal. Contrast the output of
with

No, I am saying they update / patch all the time, SOME are kernel updates. And as I read the update lists it is on a 'needed' basis. ( ie kernel or not)

Not everything has to be patched / fixed in kernels.

BV206 wrote: Sun Apr 14, 2024 4:00 pm Are you saying that everything listed at https://www.debian.org/security is a linux kernel update?

I think it's pretty obvious from the naming convention that the March 2024 "DSA-5645-1 firefox-esr" security update doesn't involve the kernel. Grepping the list of 2024 security updates, three of them were kernel updates. Two in January, one yesterday. If you'd like to update your kernel every couple of days it's possible to track the mainline kernel directly, though you'll quickly discover that the Debian kernel team puts in a lot of work before they publish something you can simply add with the convenience of "apt-get install linux-image-something". There's plenty of information on https://wiki.debian.org/DebianKernel to get you started.

... For example for the LTS kernel 6.1.0-20-amd64 from Debian, it is from the 6.1.85 linux.org ... so 20/85, the frequency is at 23.5%, almost 1/4 linux.org changes.

Updating a kernel and then actually pushing it out for all the world is actually 2 very different things. It takes man hours to vet it after writing it in the first place.

oops wrote: Sun Apr 14, 2024 7:54 pm ... For example for the LTS kernel 6.1.0-20-amd64 from Debian, it is from the 6.1.85 linux.org ... so 20/85, the frequency is at 23.5%, almost 1/4 linux.org changes.

What's apples divided by oranges?

Debian kernel versioning is unique and separate from Linux mainline kernel versioning. You'll notice that you haven't seen a Debian 6.1.1 kernel, or 6.1.2, even though those kernels exist in linux.git. It's always 6.1.0-XX. The Debian kernel team maintains their own copy of the kernel source code, integrates upstream patches as they occur, compiles and publishes Debian-tailored updates carefully and systematically after they've performed regression testing, and after they've determined an update is both warranted and safe.

When I started using Linux, I would read change logs for kernel updates, mainly to get a sense of what zero day vulnerabilities might look like. Was a bit amused to discover how low the bar for what counts as a "security update" (e.g., someone with physical access might be able to stop a process). Meanwhile, when a serious vulnerability comes along (e.g., Boot Hole), updates happen very quickly.

pbear wrote: Mon Apr 15, 2024 10:59 pm When I started using Linux, I would read change logs for kernel updates, mainly to get a sense of what zero day vulnerabilities might look like.

Meanwhile, when a serious vulnerability comes along (e.g., Boot Hole), updates happen very quickly.

The irony here in following the public changes is that serious security problems are not discussed on LKML, but on a secret, select mailing list. This is how the top Linux kernel maintainers, meaning Linus and his lieutenants, discuss serious vulnerabilities, outside of the public eye, to coordinate with researchers and vendors to introduce patches so that they can be pushed before the underlying flaw is announced.

DukeComposed wrote: Mon Apr 15, 2024 9:50 pm

oops wrote: Sun Apr 14, 2024 7:54 pm ... For example for the LTS kernel 6.1.0-20-amd64 from Debian, it is from the 6.1.85 linux.org ... so 20/85, the frequency is at 23.5%, almost 1/4 linux.org changes.

What's apples divided by oranges?
...

It is mostly an approximation to summarize the problem, and to show the potential loss of time and energy. (to compile and install all these type of kernels)

oops wrote: Tue Apr 16, 2024 6:40 am ... summarize the problem

What problem? I've never heard of a malware attack in the real world coming in through a Linux kernel vulnerability, not even a zero day never mind a patch in the works. Have you?

Anyhoo, if you don't like the Debian kernel update schedule, use something else. The schedule isn't going to change any time soon.

pbear wrote: Tue Apr 16, 2024 10:57 am

oops wrote: Tue Apr 16, 2024 6:40 am ... summarize the problem

What problem? I've never heard of a malware attack in the real world coming in through a Linux kernel vulnerability, not even a zero day never mind a patch in the works. Have you?

There have definitely been exploited real world vulnerabilities on kernels. PwnKit and DIrty Pipe come immediately to mind. If you really want to know more, you can search here for linux or kernel and hunt them down.
https://www.cisa.gov/known-exploited-vu ... log?page=1

pbear wrote: Tue Apr 16, 2024 10:57 am

oops wrote: Tue Apr 16, 2024 6:40 am ... summarize the problem

What problem? ...

The stupid and potential loss of time and energy for almost nothing. (for only small and particular changes, to compile and install all these type of kernels too often)

oops wrote: Tue Apr 16, 2024 11:31 am

pbear wrote: Tue Apr 16, 2024 10:57 am

oops wrote: Tue Apr 16, 2024 6:40 am ... summarize the problem

What problem? ...

The stupid and potential loss of time and energy for almost nothing. (for only small and particular changes, to compile and install all these type of kernels too often)

Sounds like what happens with a typical Arch install.

oops wrote: Tue Apr 16, 2024 11:31 am The stupid and potential loss of time and energy for almost nothing.

The primary function of the kernel is the interface between operating system and hardware. Testing how well it does that job isn't nothing. It's already been explained that's why Debian takes longer to turn around kernel updates. I see lots of threads on Ubuntu and Mint forums about kernel upgrades creating problems. On Debian and MX? Not so much.

CharlesV wrote: Tue Apr 16, 2024 11:19 amIf you really want to know more ...

Spent ten minutes. Found confirmation of bugs, nothing about exploits. Notice I never said it doesn't or can't happen. Risk is about probability, though, and risk management almost always entails a cost.

... Right, The main function of the kernel is the interface between the operating system and the hardware. It must also not untimely disturb the end user (and the packager) with untimely updates.

pbear wrote: Wed Apr 17, 2024 12:50 am

oops wrote: Tue Apr 16, 2024 11:31 am The stupid and potential loss of time and energy for almost nothing.

The primary function of the kernel is the interface between operating system and hardware. Testing how well it does that job isn't nothing. It's already been explained that's why Debian takes longer to turn around kernel updates. I see lots of threads on Ubuntu and Mint forums about kernel upgrades creating problems. On Debian and MX? Not so much.

CharlesV wrote: Tue Apr 16, 2024 11:19 amIf you really want to know more ...

Spent ten minutes. Found confirmation of bugs, nothing about exploits. Notice I never said it doesn't or can't happen. Risk is about probability, though, and risk management almost always entails a cost.

The link that I posted ... IS about "Known Exploited Vulnerabilities" ... and it states
"CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild"

Not sure what more you need for confirmation.. that catalog ARE exploited issues.

CharlesV wrote: Wed Apr 17, 2024 12:46 pm Not sure what more you need for confirmation.. that catalog ARE exploited issues.

Actually, I found the website so painful to use as to be worthless. With no assurance it would be topical, as the point under discussion was kernel exploits, not exploits generally. What I spent some time searching were the two bugs you mentioned (PwnKit and DIrty Pipe). Anyhoo, the thread has turned into Argument Clinic. I'm gonna find something else to do.