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.
> 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.
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.
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.
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?
13 comments
[ 4.1 ms ] story [ 22.3 ms ] threadhttps://news.ycombinator.com/item?id=39051159
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.
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.
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 do trust the project then why add another source of trust?