[gnfargbl]

Let's continue your reductive line of thinking. If the only purpose is to ensure that developers are talking about the same issue, then why does the kernel need need CVEs at all? Their existing bug tracking mechanisms should be entirely adequate, no?

[pdonis]

In the 2019 article that is linked to in the LWN article posted upthread, that's exactly what Greg Kroah-Hartman suggested: use the change ID that the Linux kernel is already using as a vulnerability identifier.

Unfortunately, it does not appear that that proposal gained traction, since it's not discussed at all in the more recent LWN article.

[saagarjha]

Some platforms do in fact do this. If you run the entire stack, more power to you. But the kernel is forked by a hundred different people and everyone has their own bug trackers for that, so having an identifier for a security bug is actually useful to unify those.

[gnfargbl]

I would have no problem at all with the kernel developers introducing the concept of a "universal bug identifier," and developing a system for cataloguing and managing those UBIDs. I would also have no issue with CVEs being replaced by a set of flags on those UBIDs, which people could take notice of or ignore as they saw fit.

I do have a problem with the kernel devs attempting to burn down the only system we presently have, however terrible it is, and with HN justifying the bonfire on the basis that CVEs were always broken anyway.

[tptacek]

"Universal bug identifier" is precisely the point of CVE. They're not "broken" anymore than a WONTFIX bug is.

[gnfargbl]

There's a good-faith community norm that CVEs are for bugs that the reporter believes are security-related. Sure, that norm is regularly violated, but community standards always are and it doesn't diminish their value.

[tptacek]

CVEs have been filed for e.g. memory corruption issues with no known exploit or even plausible path to exploit since time immemorial, or at least since time-since-CVE-was-invented. The idea that there is a burden of proof or certainty required to number something with a CVE is a commercial vendor invention.

It's easy to see why people want CVE to work that way! It implies that people numbering potential security issues are doing a fuckload of work for you. But that work isn't free, and CVE has other purposes in the research community. So, no, I don't think anybody is going to talk the kernel people down from this. They're right.

If you want a feed of "CVEs" that clear a plausibility bar, put that together yourself. A lot of people would love to consume it and sell it to their customers; you'll get a lot of uptake.

[gnfargbl]

It's an interesting idea, but I'm not sure the market is there for the "plausible CVE" replacement you mention. We already have EPSS and KEV, and we regularly see attempts to replace CVSS with something better -- Zoom did something recently, as did Vulncheck I think. They don't tend to get much traction.

[worthless-trash]

Just to be clear, that the CVE assigner (CNA) believes are security related, not the person asking.

This is a CNA responsibility.