Resurrecting DWF

Posted Apr 8, 2021 6:01 UTC (Thu) by NYKevin (subscriber, #129325)
Parent article: Resurrecting DWF

> The CVE project seems to feel differently, as it put out a tweet disavowing CVE IDs that do not come from the CNAs. CVE board member Tod Beardsley also filed a pull request to change the identifiers to DWF-xxxx-yyyyy, which "will disambiguate vulnerability identifiers sourced from the DWF project from those produced by the federation of CVE Numbering Authorities, and avoid any confusion in downstream users of these identifiers".

I have no sympathy for the CVE project here. It sounds like they had every opportunity to fix this problem, and utterly failed to do anything effective. The concept of "fill out a web form, get a CVE ID" is not exactly novel.

If they had instead announced that, starting tomorrow, they were going to adopt the DWF approach and deprecate the whole CNA system, I might feel differently. But that's not at all what their tweet says. Indeed, it doesn't even properly acknowledge the existence of DWF, instead referring vaguely to "CVE IDs obtained in some other way [than from a CNA]."

Unfortunately, there's a good chance this ends in some sort of ugly legal battle over trademarks. Which is a crying shame, seeing as there is a blatantly obvious way for the parties to compromise:

* DWF agrees to operate as a "real" CNA, and not a rival organization. It issues "real" CVE IDs and complies with most or all of the CNA requirements (whatever those are?).
* CVE agrees to let DWF issue enough "real" CVE IDs to fulfill their stated purposes, perhaps giving them larger or more blocks of CVEs than most CNAs get, and/or leeway with respect to other CNA requirements (to the extent that those requirements would otherwise interfere with DWF's structure, goals, or finances).

A good compromise leaves everyone unhappy, of course, but it's better than litigation. In my judgment, this is primarily CVE's mess to clean up, so I'm intentionally biasing this compromise in DWF's favor, but of course reality may result in a less equitable outcome.

to post comments

Resurrecting DWF

Posted Apr 8, 2021 9:28 UTC (Thu) by danielthompson (subscriber, #97243) [Link] (7 responses)

Terrific work on the process but I'm struggling to to wrap my head round the consequences of adopting the CVE- prefix.

Ultimately I can't agree with the assertion that CVE means vulnerability. I understand it to mean an identifier that I can look up, potentially with automatic tools in "the CVE list". Thus having identifiers that appear to be CVE numbers that are not included in the CVE list seems to be massively confusing, especially so on an identifier format that *explicitly* includes a namespace to describe the originator of an identifier.

In other words using CVE in this context appears to be exactly the sort of misrepresenation regarding the originator that trademark law was intended to prevent. Of course that is not to say that it will or won't apply in this case... but it is the societal benefit trademarks are intended to provide.

Resurrecting DWF

Posted Apr 8, 2021 10:42 UTC (Thu) by jkingweb (subscriber, #113039) [Link] (1 responses)

> Ultimately I can't agree with the assertion that CVE means vulnerability. I understand it to mean an identifier that I can look up, potentially with automatic tools in "the CVE list". Thus having identifiers that appear to be CVE numbers that are not included in the CVE list seems to be massively confusing, especially so on an identifier format that *explicitly* includes a namespace to describe the originator of an identifier.

You have identified what I've been struggling to pin down about this that I don't like. If I see CVE 1000003 and I'm not aware of DWF (I certainly wasn't before today), how do I find the particulars? Not MITRE, despite the prefix that has been well known for two decades. How do I figure out, without prior knowledge, that I should be looking for the DWF database? This uses CVE identifiers without gaining any of the practical benefits of having them, while stepping on toes in the process.

Resurrecting DWF

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

You use a search engine like Google, just like you do now. Hint: legacy MITRE CVE IDs don't show up in the database immediately, the SolarWinds stuff took many days to show up after they were publicly used by Solar Winds/etc.

Resurrecting DWF

Posted Apr 8, 2021 13:46 UTC (Thu) by mjcox@redhat.com (guest, #31775) [Link]

For the CVE boards perspective see "Message to DWF from the CVE Board" at
https://github.com/distributedweaknessfiling/dwf-workflow...

Resurrecting DWF

Posted Apr 8, 2021 23:36 UTC (Thu) by cjwatson (subscriber, #7322) [Link] (3 responses)

I help maintain a website (launchpad.net) that among many other things imports CVE information from the XML dump provided by MITRE and auto-links references that people make to them from other parts of the site: this means that for instance if people mention CVE-something in a bug report then it's easy to click through to all other bug reports on Launchpad that relate to the same CVE identifier. What should we most correctly do now that there seem to be arguably two authorities for the same namespace?

(This is not a loaded question: I'm not a security researcher nor somebody particularly invested in the existing CVE system. I just want to figure out what we should be doing to track this in case people use these new DWF-issued identifiers on Launchpad and expect them to work the same way, which seems likely. "Use a search engine" isn't an option here: we maintain these links automatically and want to keep it that way.)

Resurrecting DWF

Posted Apr 9, 2021 0:44 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

Presumably just pull in the DWF feed too and link to the DWF advisories when the CVE number doesn't appear in the MITRE advisories?

Resurrecting DWF

Posted Apr 9, 2021 8:30 UTC (Fri) by cjwatson (subscriber, #7322) [Link] (1 responses)

That is certainly an idea I'd already had, but I can think of at least three possible approaches so I was hoping for one of the DWF people to clearly state what they recommend in this sort of situation.

Resurrecting DWF

Posted Apr 18, 2021 20:07 UTC (Sun) by kurtseifried (guest, #57307) [Link]

We provide our data via GitHub, we don't (yet) provide other formats such as a CSV/etc., they lose too much data to be truly useful in my opinion (but if someone wants to make that happen then file an issue to discuss and we'll accept code most likely). Continuous ingestion via GitHub really is the best rather than waiting hours or for a daily snapshot that contains less information.

Resurrecting DWF

Posted Apr 8, 2021 18:11 UTC (Thu) by kurtseifried (guest, #57307) [Link] (1 responses)

When the DWF originally started (2016) it did previously become a CNA (a whole messy story), we already tried this, it didn't work in my opinion, so I shut down the DWF, and now Josh has helped resurrect it and we'll see how it works out.

Ditto for being a member of the CVE Board, I retired from it in Jan 2021. We really tried to change from within.

Resurrecting DWF

Posted Apr 10, 2021 22:55 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

Just to clarify: I am not trying to propose a solution which is perfect, or even necessarily all that good. I am trying to propose a solution which does not end in litigation.

If y'all have lawyers and are prepared for this fight, I wish you luck. If not, then I think you should hire some. Because I simply cannot imagine the CVE people letting this go.