The Linux kernel is 38 million LOC. #curl is 170K. The kernel is 223 times bigger.

The Linux kernel ships 60 CVEs per week, 3100 per year.

curl ships on average 13 CVEs per year, 3100/223 = 14

== Roughly the same CVE/line of code ratio.

@bagder Do you know what proportion of them are memory-related?

@AugierLe42e for #curl issues, we know that the "C mistake" share is a little over 40%. Those are mostly memory related.

@bagder if you actually go read the kernel 'CVEs' you'll see that this rationalisation is simply inaccurate.

Greg is trolling the system it's as simple as that. But ah well.

@bagder What about the rest?

@AugierLe42e they are not C mistakes. Typically logical mistakes of various sorts.

@bagder Ok, thank you.

@ljs I don't think I would be qualified to judge that

@bagder I don't claim to be an authoritative expert on all, but it's a widely held opinion among kernel devs (at least those I have spoken to in person). And there are numerous examples of questionable things.

Essentially all commits tagged as fixes are assumed to be exploitable security flaws.

You could go further and argue every single commit is a potential security flaw, and by the logic applied, that is absolutely valid. Luckily Greg hasn't quite gone that far...

The issue is there are serious downstream effects for enterprise kernels whose customers demand that CVEs are addressed, so overnight companies have to scramble to handle the deluge.

Of course this all speaks to CVEs being a poor system for this kind of thing, which is why this troll is happening, a sort of 'well the official definition of a CVE is X so I will give you all the Xes'.

Anyway it's all a bit moot, this is just how things are now...

@ljs sure, but I believe the opposite is also true: the frequency is just so high so people can't spend enough time and energy to full go to the bottom of each possible flaw there.

@bagder Right, but it becomes a question of filtering the noise, the ones that are actually security flaws will still eventually get dealt with, just a bunch of extra work on top now.

I mean if I want to be positive about it - I think the number of security flaws in the kernel is way way higher than many think.

So perhaps this wakes people up to that and leads to more work on improving things.

But I you know, no I don't think so, I think this is just not a good thing :>)

The ideal outcome would be for a new system to emerge that is more sensible and targeted at actual security flaws rather than assigning a CVE as early as possible to 'could be' stuff.

@bagder @ljs my experience as a GDB developer, a project with extremely minimal security requeriments and an unreasonable amount of CVEs says otherwise. The general rule send to be that if it looks like security and smells like security it turns into a CVE to make my CV Exceptional

And so you get people saying "you can fresh GDB by feeding this python code (...)" as is it was a denial of service attack when "system exit(0)" will also quit GDB. And many similar regarding reading debug information, where they don't even bother to think of the internal error (which is actually a failed assert, basically) is exploitable or was detected early enough

@bagder @ljs and it was also the experience of a good few security researchers I have seen, CVE and MITRE aren't doing a decent job of filtering things, and they prefer to have everything be a CVE than maybe let one real thing pass

@GwenTheKween @bagder yup, which is where you can have some sympathy for Greg's troll (he says it's not, I think it is, I've said all this to him directly so no back biting here).

But it causes downstream harm, which is why I have an issue with it.

The funny (but also tragic) thought is, if it's a troll designed to highlight how worthless CVEs are, when people rationalise + accept the pace of kernel CVEs then it causes the troll fails...

@bagder

If we math this out, that's around 1300 lines of code per vulnerability

The @ecosystems folks are tracking 200 million repos and 9 million packages

2024 will see about 40,000 CVE IDs total

This is fine

@joshbressers @bagder @ecosystems current package count is 10.5 million 😅

@andrewnez @bagder @ecosystems hah, so it is!

@joshbressers @ecosystems one CVE per 13K LOC per year according to my math.

So if 10 million packages average at 100K lines each (blatant assumption), we could be looking at about 76 million CVEs/year. =)

@bagder @ecosystems hah, still too early for math

But yeah, the numbers are staggering

@joshbressers @bagder @ecosystems although there’s a huge amount of npm spam in there, so it’s probably closer to 8m of real-ish things

@andrewnez @bagder @ecosystems It’s completely mind boggling that 2 million could be spam and there’s still 8 million left

@bagder sorry, but what is CVE?

@lidicrous a CVE is a public unique identifier for a security vulnerability in a software product. https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures

@ljs @bagder @GwenTheKween in a way, you could argue this is basically the logical extension of the Linus quote "security problems are just bugs" from 2017

@gigantos @bagder @GwenTheKween that position was rescinded after Greg decided to start trolling. I liked that position. Sigh.