A thought that popped into my head when I woke up at 4 am and couldn’t get back to sleep…

Imagine that AI/LLM tools were being marketed to workers as a way to do the same work more quickly and work fewer hours without telling their employers.

“Use ChatGPT to write your TPS reports, go home at lunchtime. Spend more time with your kids!” “Use Claude to write your code, turn 60-hour weeks into four-day weekends!” “Collect two paychecks by using AI! You can hold two jobs without the boss knowing the difference!”

Imagine if AI/LLM tools were not shareholder catnip, but a grassroots movement of tooling that workers were sharing with each other to work less. Same quality of output, but instead of being pushed top-down, being adopted to empower people to work less and “cheat” employers.

Imagine if unions were arguing for the right of workers to use LLMs as labor saving devices, instead of trying to protect members from their damage.

CEOs would be screaming bloody murder. There’d be an overnight industry in AI-detection tools and immediate bans on AI in the workplace. Instead of Microsoft CoPilot 365, Satya would be out promoting Microsoft SlopGuard - add ons that detect LLM tools running on Windows and prevent AI scrapers from harvesting your company’s valuable content for training.

The media would be running horror stories about the terrible trend of workers getting the same pay for working less, and the awful quality of LLM output. Maybe they’d still call them “hallucinations,” but it’d be in the terrified tone of 80s anti-drug PSAs.

What I’m trying to say in my sleep-deprived state is that you shouldn’t ignore the intent and ill effects of these tools. If they were good for you, shareholders would hate them.

You should understand that they’re anti-worker and anti-human. TPTB would be fighting them tooth and nail if their benefits were reversed. It doesn’t matter how good they get, or how interesting they are: the ultimate purpose of the industry behind them is to create less demand for labor and aggregate more wealth in fewer hands.

Unless you happen to be in a very very small club of ultra-wealthy tech bros, they’re not for you, they’re against you. #AI #LLMs #claude #chatgpt

@manx @bagder @defnull @pierstoval Your proposal seems to match what is currently available to you by asking for a CVE id from the existing CNAs that offer them (red hat and github). You always need a person involved in the process, and those two CNAs are giving you their time and resources to do this for you, for free. If you don't want the delay involved in using that resource, then again, you can spend a bit of your own resources (i.e. time, one time) to become a CNA so that you don't have to rely on others in the future.

Any system of "global identifiers" is going to do the same exact thing, this isn't unique to cve.org at all. It's just that cve.org actually allows you to take ownership of your own destiny, instead of being forced to rely on others, if you so desire.

@manx @defnull @bagder @pierstoval If there are steps involved that you feel are unneeded or "too much effort", let them know, they are responsive to making this process easy to work with.

Personally, I didn't find it took that long at all.

@manx @defnull @bagder @pierstoval There will always be something that has to be a "gatekeeper" to get access so that you can assign identifiers, otherwise the system is useless and will be flooded with junk.

There are other alternatives to CVE, if you don't want to go through the "hoops" that cve.org puts up, but all of those alternatives also require a basic "here's how you work with our system and let's verify you are a real person/group to be using it", which all amount to pretty much the identical effort involved.

So it's fun to wish for free ponies, but someone has to be responsible for taking care of it :)

8 minutes video of commuting in the snow by bike here in the Netherlands earlier this week:
https://www.youtube.com/watch?v=SmMRVeRs3vU
(note, not my video, but I was out in that mess, taking a tram and walking to where I needed to go that day.)

@pierstoval @defnull @manx @bagder Again, we have that today, there is a "one click submission to assign a CVE web form" that a CNA can use (and many do.)

So I really don't understand what you are wanting to see created that isn't already here for you to use today.

@pierstoval @defnull @manx @bagder Um, we have that today, with the CVE infrastructure. Any open source project can become a CNA now, and once that is done, they have access to do everything you are asking for.

There is always going to be a "hurdle" of signing up to get that token/oath/whatever, which is what the process is for in becoming a CNA (proof you know how to issue a cve properly, using the tools). So no matter who "hosts" this thing, it's going to be the same.

Try it yourself and see!

@manx @bagder There is no work involved in "maintaining" a CNA, other than actually doing the normal work of being a CNA by assigning CVEs to your project when needed.
Yes, it takes a small bit of time to become a CNA, but it's really painless and it involves a small amount of homework to show that you know how the process works, which is a good thing for everyone involved. Once completed, being a CNA is trivial.

But if you don't want to be one, fine, just hit up a CNA that can give you a CVE id if needed for your project (Red Hat and Github do this for open source projects), but then you are at the mercy of their workloads, not yours. It all depends on who you wish to depend on, someone else, or yourself :)

@manx @bagder It does not take longer than that, it's a "simple" api call (i.e. a scripted curl command) that any CNA can do to get a CVE number, and you can allocate any amount at once (within reason, CNAs have a max they are allowed to request and "hold" without assigning at any point in time, usually around 500 or so.)

Another post in my Linux kernel CVE process series, "How the Linux kernel security process works": http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

I've been trying to quit Google for years, and I finally did it: https://jimmunroe.net/writing/divestment-december.html
Anger at the techno-fascists wasn't enough on its own:
I got a big boost of inspiration and mutual aid from the brilliant community at @yunohost who provide ways to install and maintain -- with very little technical knowledge --
digital services like forums, cloud services and media streaming apps. Check them out at https://YunoHost.org !

All 5960 GSD kernel security reports are now finally processed and CVE ids have been assigned for those that meet the cve.org criteria. Only took me almost 2 years of manual review, ugh, that was a grind:

https://lore.kernel.org/r/2025123055-directory-hemlock-a282@gregkh

The kernel CNA assigned their 10000th CVE last week, CVE-2025-68750

So far the “stats” look like:

 Year	Reserved	Assigned	Rejected	 A+R		Returned	Total
  2019:	   0		   2		   1		   3		  47		  50
  2020:	   0		  17		   0		  17		  33		  50
  2021:	   0		 732		  24		 756		  16		 772
  2022:	   3		2041		  47		2088		   0		2091
  2023:	   1		1464		  47		1511		   0		1512
  2024:	   6		3069		  96		3165		   0		3171
  2025:	  73		2421		  39		2460		   0		2533
 Total:	  83		9746		 254		10000		  96		10179

Note, the “year” is the year the bug was fixed in the kernel tree, NOT the year the CVE was applied for/assigned.

@trashheap The “argument” by the SFC is complete garbage, and always has been. There has been no question about the license, and I have made it very clear over the years. And the SFC knows that.

So when they argue their incorrect reading of the GPLv2 in court, they are absolutely not doing GPLv2 enforcement. They are trying to further an agenda that is invalid, and always has been, and is explicitly against the wishes of the actual copyright holders.

So the SFC is just pure trash.

If they want to “protect” some project, let them protect a project that asks for it - not one that is known to not want their kind of protection.

Because what they are doing is a racket, plain and simple.

Rare footage of @gregkh signing an autograph with the phrase "do not use old kernels!" at Open Source Summit Korea 2025, after one of his sessions.

#Linux #OpenSource #OpenSourceSummit

Just found that the 2026 edition of the Linux Plumbers Conference will be in Prague 🇨🇿 , Oct. 5-7, on the same week as Open Source Summit Europe and Embedded Linux Conference Europe.

Save the dates and see you there! That's too early to book my train tickets though 🤔

https://lpc.events/event/20/

Whenever I see a “rice my Arch #Linux w/hyprland” video, I’m like:

You think that’s badass? You should’ve tried getting X11 running on a Linux machine in the mid-90s. You needed your monitor & video card manuals & a calculator (seriously) so you could calculate “modelines” for your X11 config file.

If you got the math wrong you’d fry your monitor by driving it at too high a frequency (back then nearly all monitors were fixed-frequency).

Typing “startx” for the first time was *so* stressful.

Stephen Rothwell is "stepping down as #Linux-Next maintainer on Jan 16, 2026. Mark Brown [@broonie] has generously volunteered to take up the challenge.":

https://lore.kernel.org/linux-next/20251218180721.20eb878e@canb.auug.org.au/T/#u

To quote: ""It seems a long time since I read Andrew Morton's "I have a dream" email and decided that I could help out there - little did I know what I was heading for.""

Many many thx Stephen for all your really hard work on this over all those years, it helped a tremendous lot!

#LinuxKernel #kernel

Interesting tidbit about Rust as used in the Android OS: to prevent the trusting trust attack, and not rely on rust-lang.org build, they bootstrapped rustc 1.19 with mrustc (0.8.0), and then built all following rustc versions with their previous version.

https://cs.android.com/android/platform/superproject/main/+/main:prebuilts/rust/bootstrap/README.md

#RustLang #Android #Toolchains #Bootstrapping #TrustingTrust

Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase.

That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.

Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.