@GrapheneOS Nope, that's not why LTS merges are being done slower in the Android kernel trees, there are a variety of other external reasons why that has slowed down. Nothing to do with my CNA work, sorry to spoil your narrative.

You know, a simple email asking "hey, why is this going slower" could have solved all of this speculation...

@vbabka @itaru It was not me, it was Linus over a year ago and I acked the change, as did the LF head of legal, see the commit log text for more information about it: https://git.kernel.org/stable/c/d4563201f33a022fc0353033d9dfeb1606a88330

@kurtseifried "Message-ID: <51D1F685.5050608@redhat.com>" should give you a hint of what to search for...

@sageofredondo @ljs @kernellogger @sandeen @vegard Android kernels provide a kABI guarantee as well, and have been taking the LTS releases for many many years now (using the tools that a RH developer helped create to ensure a stable kABI, and contributing to them to make them better for you to use as well), so that's really not a valid reason to refuse stable updates, sorry :)

@somenxavier Sorry, but that doesn't make any sense, udev is part of systemd and has been for a very very long time. If you have udev questions, please ask them on the systemd mailing list.

@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