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...
=== 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
@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.
@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.
Many thanks to Lyude and Danilo and many other Rust kernel developers for the help in creating the binding and make the C side work well for both Rust and C code at the same time. The end result here for any C developer alone, is much better off for all of their help.
@bagder Oh crap, yes, that does work on this model! It's even buried on the spec sheet if you read it close enough. It didn't on a previous model I had, so I'll blame that reason why I never tried this out. Ok, one less cable to carry around with me when traveling now, thanks!
Embed this noticeGreg K-H (gregkh@social.kernel.org)'s status on Monday, 27-Jan-2025 22:11:04 JST
Greg K-HScariest cable I have that I actually use. It's a USB-C to Thinkpad "adapter" that I bought to power a thinkpad that shipped with a giant 135W brick-of-a-power-supply. This cable does work, but has the tendency to "overload" many USB chargers, causing them to reset. Fun times, but good for traveling so I don't have to lug the brick around with me as well.
@alwayscurious@sima@sourcejedi That's one reason, the other one was "power just glitched, my printer better be on the same device node it was before it was turned off". Same for keyboards, mice, disks, etc.
@alwayscurious@sima "Normal" PCI hotplug systems should export this information, as the BIOS expects a user to add/remove PCI devices on a slot basis. Otherwise why would a BIOS care about exporting the slot number at all. So it's not required, and you are lucky if it shows up. good luck!
@joshbressers Linux is only #6? We better get on that to reclaim our 2nd ranked spot of last year despite only participating for 10 1/2 months, not the full 12 everyone else was able to have! :)
@alwayscurious@sima@sourcejedi Again, reuse of major/minor numbers was a design requirement at the time. And, you know the path / label / metadata / whatever for the block device before you mount it, so go off of that information if you don't trust the device major/minor number information.
@alwayscurious@sima PCI devices, at the bus/slot/function level do not have device nodes, so I don't understand the issue here.
They might have a specific PCI driver bound to them, at the function level, and if so, the parent of the device node for that class device (i.e. input, tty, drm, etc.) will then point to that PCI function. But PCI slots don't always match up to PCI bus and device numbers either, as that's a physical thing and many PCI systems don't expose or even know that information (i.e. the BIOS doesn't know.)
Also, PCI bus numbers can change at boot, so you can't know what is happening.
Driver probing can be deferred at any time by userspace for USB devices, and I think that was recently added for PCI devices too, look for the "trusted" device information in the documentation somewhere.
@aho Thanks for the info, I'll look into it when I get a chance! I've fixed my original problem for now, so odds are I'll live with it until something breaks again.
@alwayscurious@sima@sourcejedi That ship sailed decades ago as we had to support device node reuse a long time ago, it was a requirement! But obviously not your requirement :)
You have full control over device node creation in userspace, that's what udev gives you if you want (or any udev-like program). set up a whole different /dev/ with just your naming/numbering scheme. The kernel gives you the interface and the information to do this, why not take advantage of it if you need it?