Curl is now a CVE Numbering Authority(daniel.haxx.se)
daniel.haxx.se
Curl is now a CVE Numbering Authority
https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/
5 comments
[deleted]
> In plain English, this means that we will reserve and manage our own CVEs in the future directly against the CVE database with no middle man, and also that we have a scope for CVEs that is our territory: curl and libcurl
Combining this and the announcement of the same for PostgreSQL, would be even better if each was the authority for the other. I’d trust either project to classify the severity of an issue in the other.
Being able to classify your own CVEs has a bit of a fox watching the hen house vibe to it.
Combining this and the announcement of the same for PostgreSQL, would be even better if each was the authority for the other. I’d trust either project to classify the severity of an issue in the other.
Being able to classify your own CVEs has a bit of a fox watching the hen house vibe to it.
Being able to classify your own CVEs has a bit of a fox watching the hen house vibe to it
yes, but no. from the article:
There’s an appeals process so someone can still actually file CVEs for issues even if we say no, but at least there’s a process where both sides will argue their points.
which is how filing for CVE should have been organized to begin with.
noone should ever be able to file a CVE without the product owner having a say in this.
filing a CVE should always include the party that is responsible for the vulnerability with proper checks and balances.
the current process allows accusing someone without the accused having any ability to defend themselves. it was created with the expectations that only security experts who know what they are doing will file CVEs. that expectation has not held.
this is pretty much why linus thorvalds refused to announce when they fix security issues in the linux kernel.
yes, but no. from the article:
There’s an appeals process so someone can still actually file CVEs for issues even if we say no, but at least there’s a process where both sides will argue their points.
which is how filing for CVE should have been organized to begin with.
noone should ever be able to file a CVE without the product owner having a say in this.
filing a CVE should always include the party that is responsible for the vulnerability with proper checks and balances.
the current process allows accusing someone without the accused having any ability to defend themselves. it was created with the expectations that only security experts who know what they are doing will file CVEs. that expectation has not held.
this is pretty much why linus thorvalds refused to announce when they fix security issues in the linux kernel.
If you don't trust the project to communicate its own vulnerabilities why would you trust the project's secure coding and vulnerability management practices?
If you do trust the project then why add another source of trust?
If you do trust the project then why add another source of trust?
The author directly addresses your concern at the bottom of the post. There’s also a link to the context for why they had to do this and a reluctance for the authority.
Wow, that's some history to this. I used to believe MITRE deserved some respect, but now, I'm not sure I do anymore.
When traffic is mad, one either drives the bus or goes under it, apparently.
You can't ride the bus?
I honestly can't figure out what this means.
If you don’t drive the bus (act as the numbering authority), then you’ll be hit by the bus (get bogus CVEs) and end up under the bus.
It is a reference to the high-severity CVE kerfuffle that the Curl project was exposed to recently:
https://news.ycombinator.com/item?id=39051159
https://news.ycombinator.com/item?id=39051159
No need to use curl, make HTTP requests great again with https://github.com/ducaale/xh
Last year, someone got got CVE's assigned for a curl issue for code that didn't exist AND managed to get a high severity assigned to it. So curl becoming a CNA lets them provide some control to this process.