@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

Eight new stable kernels https://lwn.net/Articles/966755/ #LWN

@jarkko "They all do different things, but yet are alike, and none are real, yet all directly control how the system works. Use them at your own risk as touching almost anything in them is a sure way to crash your system."

:)

Any job that asks you that type of question is just trying to mess with the applicants, stay away from that type of place as much as possible.

@drewdevault I think I can save you a step here, we did a research paper on this a few years ago.

"Do Software Developers Understand Open Source Licenses?"

https://www.cs.ubc.ca/~murphy/papers/licensing/software-licensing.pdf

To my chagrin my co-authors overruled me, but in my first draft the abstract was just:

"Nope."

Minister Adriaansens: verhuizing SIDN naar Amazon 'nog geen voldongen feit' https://tweakers.net/nieuws/220102/minister-adriaansens-verhuizing-sidn-naar-amazon-nog-geen-voldongen-feit.html

For your Sunday reading: https://arxiv.org/pdf/2402.05212.pdf "An Investigation of Patch Porting Practices of the
Linux Kernel Ecosystem" in which different distros, and Android, are evaluated as to how up to date they stay with upstream fixes. Note that RHEL or CentOS is not evaluated "because of the lack of public git repositories or insufficient data."

About time someone started writing papers about this stuff...

@takaswie Send the revert!

@liskin @oleksandr having everyone introduce themselves with the distro they use sounds about like the right kind of silly to me ;)

We're #hiring at the @openssf !

Our mission is to ensure the security of open source software for all.

Are you a seasoned Technical Program Manager excited about #cybersecurity and #opensource who wants a full-time #remotejob?

Apply: https://openssf.jobboard.io/jobs/314008394-technical-program-manager-at-openssf

@vegard @ljs @kernellogger @larsmb @pavel "security impact" means you have to take into account your specific use case, and we have no idea what your use case is Remember, Linux is in cow milking machines, servers, helicopters on Mars, phones, utility meters, watches, mega-super-yacht-stabilizers, wind turbines, printers, cars, planes, trains, and more. Doing an accurate "security impact" is going to be different for all of those cases.

To quote Ben Hawks, "It's hard to capture the fact that a bug can be super serious in one type of deployment, somewhat important in another, or no big deal at all -- and that the bug can be all of this at the same time. Vulnerability remediation is hard."

His full post is worth reading: https://blog.isosceles.com/what-is-a-good-linux-kernel-bug/

@larsmb @vegard @pavel @kernellogger I find it hard to understand how this is an "attack", when it was specifically authorized and endorsed by the CVE employees and board of directors? They knew exactly how many CVEs we would be filing on a weekly basis and how we would be evaluating them for inclusion. We went through many meetings and discussions before our application was accepted and our id submissions were allowed.

They also asked us to backfill the database with our previously submitted GSD information, as well as everything that gets merged forward. That backfill work is ongoing and is the large volume of what is currently being assigned right now. That information has already been out there for years in GSD, putting it in CVE doesn't change the actual kernel commits or "security" at all, it's just that you might not have noticed the GSD entries (hint, the "bad guys" sure did...)

The number of "new" CVE entries is a small % overall as we really have only processed the changes from v6.7.0..v6.7.3 or so. We are behind in the new stuff and will catch up soon there, help is always appreciated, if you see a commit you want assigned a CVE, just ask!

As others have said, this hasn't changed how the kernel commits are merged at all, it's just calling stuff out that everyone should have already been looking at and merging already, with way more meta-data and information than has ever been done before for kernel CVEs, thereby actually raising the information level in the CVE database here (which is probably why the CVE board wanted this.)

If companies are somehow dictating that they MUST look at and evaluate all CVEs, then they should be happy as many groups were intentionally abusing the CVE process for the kernel previously, making their life much more difficult (including the community's life, which is why we became a CNA.) That abuse has now stopped, to be replaced with a different workflow with way more meta-data produced to help make decisions easier. So far one of the biggest complainers was the company that was doing that abuse as they are no longer allowed to do that (to be specific, that was NOT SuSE).