Hacker News new | ask | show | jobs
by arp242 841 days ago
This reminds me a little bit of the people saying things like "actually, Java is not "True Object Orientedâ„¢* because it's not about messaging like in Smalltalk", and things like that. Well, okay, fine, but it seems undisputable that the phrase "Object Oriented" is used to describe OOP as implemented in Java. When millions of people understand a term "wrong", then that becomes "correct" on virtue of it being so widely used. I mean, modern English is just old English spoken badly by Vikings and Normans, right?

That's kind of how things work, and not much you or I can do about it.

So we need to think about "What is practical?" and "what is useful?", keeping these realities in mind, rather than insisting on "this is what it was meant to be".

Personally I think a good start would be to rethink the entire messaging and list them as "high impact bugs you probably want to get fixed ASAP", or something along those lines, rather than "security bugs". This should avoid the whole security wankery with memory issues that perhaps maybe possibly could perhaps someday lead a possible exploit maybe.

1 comments

CVEs are categorically not "high impact bugs you probably want to get fixed ASAP". If you want that, make a new enumeration.
They're also, equally categorically, not "a list of every bug in every system." If you want that, make a new enumeration.

As 'arp242 says, we need to consider what is useful. Pretending that all CVEs are severe and must be addressed immediately is not useful. Spamming the CVE database with every bug in your tracker is not useful.

Replacing CVEs (and CPEs, which are equally terrible) with something new would be extremely helpful. My question is, who funds that work? NIST currently appear to have NVD resourcing issues, based on the banner on their website.

> When millions of people understand a term "wrong", then that becomes "correct" on virtue of it being so widely used
I don't think this applies here. People literally agree that CVEs are the identifiers beginning with CVE-xxxx published by CNAs. They don't for example, think they're ticket numbers from the Apache bug tracker. The fact that they use them as if the criteria for publishing a CVE was more rigid, doesn't actually make that criteria more rigid.