Posts
300
Following
86
Followers
3180
repeated

Long but cheering+ practical from @bert_hubert

https://berthub.eu/articles/posts/a-coherent-non-us-cloud-strategy/

"Europe has ample compute capacity and skills.... the carrot won’t be enough to make Europe sovereign again. We must have our own technology under our own control, but we must also make sure that it gets used"

1
4
1
@ljs I'm confused, AUTOSEL is there to pick up stuff that people don't tag that look like other bug fixes, it was created because many subsystems/maintainers do NOT tag anything, so this is needed to get those fixes.

For subsystems/authors that do properly tag them, and don't want to get picked up by AUTOSEL, let us know and they can be added to the list not to.

I thought that is what you were referring to here, if not, then I think it's time to just discuss it over beers in person :)
1
0
0
@ljs If you don't want stuff picked up by AUTOSEL, let us know and you can be added to the regex of files / directories to ignore. Many subsystems do as they do properly tag stuff. But for all the others, that's why AUTOSEL is there.
1
0
1
Sasha's "AUTOSEL" logic has been revamped and published so that now you too, can dig in the Linux kernel commit logs to find patches that developers and maintainers forgot to tag to be backported to stable kernels:

The announcement:
https://lore.kernel.org/all/aBj_SEgFTXfrPVuj@lappy/

And the code itself:
https://git.sr.ht/~sashal/autosel
1
5
20
@mansr @broonie @geert It's a bot, and it is saying "next time, please properly mark this for stable backport as that is what you are saying you want to have happen, but yet that's not what is going to happen with the tags you provided".

If you can think of better wording for this, please let me know. Don't take bots personally please, they are trying to help.
0
0
0
@geert @mansr @broonie No, it's not guaranteed to be backported at all, cc: stable is still required if you want it to show up AND want to be notified if it does not apply. We get to "Fixes:" only patches on a "when we have the spare cycles let's go look for things that people did not properly mark and attempt to do a backport if it works easily"
1
0
0
repeated

Good programming is 99% sweat and 1% coffee.

— anonymous

0
1
0
repeated
Edited 9 days ago

Psst, hey: HACKERS ARE NOT TECH BROS. The vast majority of hackers never become tech bros. The ethics of hacking runs completely counter to that of tech bros.

Hackers make hardware do things they weren’t intended to do. They circumvent barriers. They string together contraptions that repurpose old stuff to do new things. Hackers aren’t that interested in money; they’re more interested in showing off their skills. They love to learn and make demos and create and share free tech that other hackers then build upon. All they want is acknoweledgement and the respect of their peers.

Tech bros are parasites. They’re greedy bastards who love to erect barriers between people and tech. They extract, addict, monetize. They turn everything fun and useful into a transaction, a dopamine trap, a subscription, a surveillance tool, an advertising outlet, and a vector to extract money from labor and suppliers.

Please don’t get them mixed up.

3
11
1
@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.
1
0
0
@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.
1
0
1
repeated

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

2
3
0
@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.
1
0
7
@aho I wish, that might actually have spit out something useful...
1
0
1
"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}
4
2
18
@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" :)
1
0
3

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
0
4
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
1
5
10
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.
1
57
85
My KubeCon "keynote" about Linux and Rust is now online: https://www.youtube.com/watch?v=d5umzdT90HU
0
21
47
Show older