Resurrecting DWF

Posted Apr 8, 2021 8:02 UTC (Thu) by mezcalero (subscriber, #45103)
Parent article: Resurrecting DWF

Not sure I get why one needs a central authority for this? Just provide a web form where you enter some data about the vulnerability, than hash that into a 128bit value or so, and prefix the result with "CVE-", and you are done. And you probably don't even need 128bit… And document how you exactly concat the stuff in a spec so that people can reimplement things independently.

The IDs would then be entirely self-managed, distributed but stable.

I mean, content-addressable databases aren't precisely a new concept?

What am I missing?

to post comments

Resurrecting DWF

Posted Apr 8, 2021 8:21 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (3 responses)

The human factor of using the identifier. CVE-2021-123456 is usable by people when referring to issues. CVE-2021- 123e4567-e89b-12d3-a456-426614174000 is not.
Usability comes from low integer identifiers. In such confined space, some kind of supervision is needed.

Resurrecting DWF

Posted Apr 8, 2021 9:06 UTC (Thu) by Karellen (subscriber, #67644) [Link]

It might be possible to treat them like git commit ids, and generally refer to them by a prefix of the full hash, e.g. CVE-2021-123e45. The full hash is still the "real" id though, and if enough are generated in a year that a collision occurs, use a longer prefix from then on.

Resurrecting DWF

Posted Apr 8, 2021 13:56 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (1 responses)

People accepted to live with git hashes. I see no reason why they wouldn't be able to do that for CVEs too. And as mentioned, you can probably shorten them a bit, or encode them in a smarter way, hex encoding is quite wasteful. you could use base32 for example, which needs 26 case-insensitive letters

Resurrecting DWF

Posted Apr 9, 2021 14:05 UTC (Fri) by hailfinger (subscriber, #76962) [Link]

"live with" implies a burden. DWF aims to reduce burdens.

Some people choose not to bear the burden of git hashes. Some of those use mercurial as a frontend for git.

Depending on your viewpoint, there is a difference between "human readable" and "can be understood by humans". A base64 encoded piece of information can be easily read character by character by a literate human being, but decoding the information without help from a computer is a rather rare skill (yes, it's easy in theory, but only few people have memorized the bit patterns).

Resurrecting DWF

Posted Apr 8, 2021 8:48 UTC (Thu) by Rigrig (subscriber, #105346) [Link] (1 responses)

I think there needs to be some verification involved, or you'd soon get botnets "finding" lots of issues with a particular product/vendor.
And even if everyone could somehow filter those out themselves, that is a lot of duplicate effort.

Resurrecting DWF

Posted Apr 8, 2021 21:48 UTC (Thu) by kurtseifried (guest, #57307) [Link]

So one major aspect of this is the quality of data. For example a security vulnerability with a trivial reproducer like the ping of death, well yeah, that's an issue. But what about "Closed source foo crashes during bad TLS handshake"... er... ok.. maybe? Can we have the producer? With OpenSource a lot of this boils down to "function() has a vuln in X, see here in line Y" which makes it trivial to verify, and more often than not the project has already replied with a "yup, that's a vuln", a great example of this is CVE-2021-1000000 with https://github.com/gpac/gpac/issues/1485 as a source, and "fixed, thanks for the report". Basically, it boils down to the quality of data followed by the trust level of the reporter (e.g. if taviso says it's a vuln, it's a vuln) followed by actually spending time validating it, Luckily for most OpenSource vulnerabilities, it's pretty easy.