@vegard @kernellogger "a team of engineers" COULD do that (hint, Android does, by just taking the stable updates), but the paper shows that a specific "team of engineers" currently does NOT do that, which puts the users of those kernels potentially at a greater risk.

Read the paper, it's interesting.

Disclosure, I read it before it was published, but had no influence on it at all.

Jeremy Allison writes:

'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"

https://ciq.com/blog/why-a-frozen-linux-kernel-isnt-the-safest-choice-for-security/ #LinuxKernel

Get out of the way of your developers or lose them to someone who will.

— Adrian Cockcroft

#management #programmers

I just got a few ideas for the next idiotic #opensource DMCA takedown notice I have to respond to...

https://bsky.app/profile/cola.baby/post/3ksffq2k5kb22

@sima @kees @kernellogger I'll gladly assign more, just send me git ids and we can do the rest :)

@kees @kernellogger Most of the rejects are not "false positives" but rather "Duplicate ID issued due to some company not putting git commit ids in their CVE records so we didn't know not to create this entry."

At least that's what is happening so far on all the rejects in 2023 and older, for 2024, those are actual "false positives" so our numbers look higher than I imagined. Maybe no one is paying attention, which could also be the case...

@kernellogger Well, some of those 1000 have been rejected, here's the current stats that anyone can check for themselves in our public git repo by running `scripts/summary` so you don't have to hack up fun `find | wc` chains like you did:

Year Reserved Assigned Rejected Total
2019: 47 2 1 50
2020: 37 13 0 50
2021: 39 304 7 350
2022: 7 43 0 50
2023: 60 180 10 250
2024: 107 435 8 550
Total: 297 977 26 1300


Anything older than 2023 is us back-filling in from the GSD database, and we still have a long way to go for there. Some 2023 ones are in there too from GSD, but mostly not, all of 2024 is since we took over being a CNA.

@DJGummikuh @ciaranmak @dokuwiki

It's overly complex (I'll try to make it simple)

The CVE project is run by MITRE and funded by the Department of Homeland Security in the US. There is a group called cve.org that is meant to be the public face of CVE. They are driving some change, but fundamentally MITRE is still driving the bus (they control the money)

The current solution the CVE group has created to deal with the huge number of CVE IDs and lack of transparency is to encourage everyone to become a CVE Numbering Authority (CNA). The idea behind that is whoever owns a product or project is responsible for all the CVEs for their scope (curl and the Linux Kernel have done this for example).

Then there is NVD which adds enrichment data to CVEs. NVD is part of NIST and not associated with CVE.

NVD has almost completely stopped enriching CVEs since the middle of February due to reasons that they won't tell anyone

It keeps getting weirder the deeper you go :)

@vegard @monsieuricon @kees @kernellogger @corbet The FAQ says the situation, I don't know why people are confused, nothing has changed in a while.

You aren't alone, Linaro had a whole "webinar" about how the world is in trouble now that LTS releases are only 2 years, despite my objections directly to them that "this is not the case".

Oh well, what do I know...

@kees @vegard @corbet @kernellogger They are? news to me :)

We start out at 2, and then after a year see what companies need/want/desire and are willing to work for having a longer period. Right now 2 years is rough, so we're doing longer.

Ideally I'd love to only do 2 years, maybe next year? Or it not, the year after that? I'm not going anywhere, we'll get there eventually as people learn that attempting to keep a fixed release on top of a highly moving project with thousands of fixes a month, is not a good idea for a variety of reasons...

@joshbressers @Di4na @kurtseifried The Linux kernel community has been using a LLM for many many years now to find security/bug-related fixes in order to flag them to be backported to stable kernels. Lots of papers were published on this, and presentations were made so you can point to lots of "prior art" here for anyone who wants to do this on their own.

"hi I am Greg, this is wrong, everything I say is public information and *not* under NDA" - @gregkh on stage of the #GoogleAndroidBootcamp

@Conan_Kudo @karolherbst the quip I usually drop on this:

upstream can remain stubborn for much longer than you can retain market share

it just takes decades, and to nvidia's credit they started to move before it got really costly for them. unlike pretty much everyone else

Saturday's stable kernel updates https://lwn.net/Articles/969732/ #LWN

Four stable kernel updates https://lwn.net/Articles/969352/ #LWN

Just a reminder: only a week to hear me babbling about Linux kernel DTS validation and shared reset GPIOs on Embedded Open Source Summit/OSSNA 2024. Don't miss it and come to say hi!
EOSS: https://sched.co/1aBEf
OSSNA: https://sched.co/1aPvr

@monsieuricon @kernellogger Oops, my fault, sorry, now tagged.

@kernellogger When someone asks us for a CVE id for a valid issue, we assign it as the process is independent of stable kernel releases. For issues that are not yet in a Linus release, we usually just reserve the id and then publish it when it has hit a -rc release, like what happened for these two CVEs.

Now when stable releases happen, we go and updated all existing CVEs to add the needed information where the fix has landed in stable kernels, and push the updates to the cve.org website in json format.

So for CVE-2024-26653, on the cve.org site, you will see that the latest stable info is included, while the older email link you provided, only says that the -rc2 is covered. But if you look in the git archive, the mbox announcement is now updated: https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2024/CVE-2024-26653.mbox

Such is the lifecycle of a kernel change, they get backported all the time...

Well, I finally have data to back my model of the software world out there. And the data is relatively solid and shows what I keep saying.

You are all on our turf now. Please accept that you have no idea what you are talking about. Sit down. Listen. Ask questions.

But respect our work. We are trying to keep the world running, 1h per month.

https://www.softwaremaxims.com/blog/open-source-hobbyists-turf

@joshbressers @Di4na Also I think people forget how much knowledge and experience it takes to make even "simple" things, if it was easy people wouldn't be grabbing open source code that does it, they'd just write it themselves in a few minutes, like padding text to the left, I mean how hard can that be? Or maybe a weekend at most for something complicated like curl, https://daniel.haxx.se/blog/2021/05/20/i-could-rewrite-curl/