@siteshwar Then someone at RHEL knows enough not to bother open source projects with obviously broken and illogical reports like that. Maybe they should have worked with the Fedora people first before sending all of this out.

@kasperd @fenruspdx Then send a real patch, as a "fix" and have the developers involved review it like any other normal type of fix that is submitted. Do NOT make a maintainer have to wade through a random report from a random tool that is filled with obviously broken and wrong reports just with the hope that maybe one of them might actually be a real issue.

In other words, do the work of weeding out the wrong reports on your end, don't ask others to do work for you just because you found the output of a free tool.

Maintainers and projects are drowning in "reports" like this, and we all have just started to totally ignore them and classify them as junk. If you don't want us to do that, then actually submit fixes instead.

This ordinary Tuesday? Two. Two AI slop security reports arrived to #curl. So far.

@kasperd None.

Have someone actually verify that they are real issues before "reporting" them to a project.

But better yet, submit a patch fixing them if you have found and determined that they are a real issue, that's the only way for anyone to take reports like this seriously.

Otherwise, it's just noise.

@aho I wish, that might actually have spit out something useful...

"Findings by static analyzers in Fedora 43" == "nonsense findings that someone wants someone else to wade through to weed out the obvious false-positives in their broken 'security' tool"

Someone needs to seriously reconsider this.

And yes, the tool is obviously broken, I looked at the first 3 "issues" found and just laughed, thinking this was a joke, but it seemed to actually be real, which is sad on so many levels...

{sigh}

@larsmb The EU is already doing this, as part of the CRA, the tender for the system implementation went out a few months ago for companies to bid on, so it's already in the works. So it was planned for already, just implementation might take a bit longer than "tomorrow" :)

More fun with CVE numbers:

=== CVEs Published Per Year ===
2024: 4451 CVEs
2025: 1502 CVEs

=== CVEs Published in Last 6 Months ===
  November 2024:  280 CVEs
  December 2024:  358 CVEs
   January 2025:  234 CVEs
  February 2025:  929 CVEs
     March 2025:  214 CVEs
     April 2025:  125 CVEs

=== Overall Averages ===
Average CVEs per month: 401.95
Average CVEs per week: 92.40
Average CVEs per day: 13.19
Statistics calculated from 2024-01-21 to 2025-04-16

And for those curious, here’s the current stats for kernel CVEs reserved/assigned/rejected since we started just over a year ago:

 Year	Reserved	Assigned	Rejected	 A+R		Total
  2019:	  47		   2		   1		   3		  50
  2020:	  36		  14		   0		  14		  50
  2021:	  20		 728		  23		 751		 771
  2022:	  20		1098		  16		1114		1134
  2023:	  20		 493		  28		 521		 541
  2024:	  20		3067		  84		3151		3171
  2025:	1837		 384		  12		 396		2233
 Total:	2000		5786		 164		5950		7950

@Pittthewelder https://lwn.net/Articles/1017565/

Given the news of the potential disruption of the CVE main server, I've reserved 1000 or so ids for the kernel now, which should last us a few weeks.

My KubeCon "keynote" about Linux and Rust is now online: https://www.youtube.com/watch?v=d5umzdT90HU

@BlackIkeEagle email the stable@vger.kernel.org list for things like this, bug reports in social media doesn't really work.

I'm sad to say that we're following the lead of many others and putting in proof-of-work proxies into place to protect ourselves against "AI" crawler bots. Yes, I hate this as much as you, but all other options are currently worse (such as locking us into specific vendors).

We'll be rolling it out on lore.kernel.org and git.kernel.org in the next week or so.

@sjvn @bagder @joshbressers @TheNewStack It's not a formal group within cve.org, just a semi-regular meeting of open source projects who are CNAs to discuss things about being a CNA.

How #Linux Kernel Deals With Tracking CVE #Security Issues: https://thenewstack.io/how-linux-kernel-deals-with-tracking-cve-security-issues/ via @TheNewStack & @sjvn

And why, all too soon, most #opensource projects must also manage their own Common Vulnerabilities and Exposures.

@joshbressers @sjvn @TheNewStack I'm with @badger Linux is a CNA to help fix the CVE process, and so far we have already achieved some change, more to hopefully come.

And the CRA is going to cause other software projects to come to terms with their reporting process, so becoming a CNA is a good step forward in the whole thing.

And besides, what open source project doesn't want to actually control what other people are saying about your project? Just this week we "took back" a CVE issued by a rogue CNA against Linux when they shouldn't have done so. If we weren't a CNA we would never have been able to do so at all.

Excellent #keynote by @gregkh at #KubeCon #CloudNativeCon on why we need #Rust in the #Linux kernel, including:

➡️ Standardize, "automate" error handling
➡️ Enforce lock acquisition, automate release
➡️ Type safety

As an important side-effect, switching from C to Rust requires you to ensure APIs fit the cleaner error handling/locking/type paradigms.

To ensure Linux stays secure and maintainers sane.

He also recommended the following 90-minute presentation: https://newsletter.pragmaticengineer.com/p/how-linux-is-built-with-greg-kroah

@jduck We assign on average, 13 CVEs a day for the kernel, what's one more? :)

Seriously, nice job, thanks for seeing the issue through. syzbot finds loads of stuff, we have a lack of people doing the work to fix everything it finds.

Many in open source are still unaware of how the Cyber Resilience Act will impact projects and businesses. This blog breaks it down.

Stay informed: https://www.linuxfoundation.org/blog/unaware-and-uncertain-is-the-open-source-community-prepared-for-the-new-regulatory-reality-of-the-cyber-resilience-act