The Linux kernel project becomes a CVE numbering authority

after the curl announcement i pretty much saw this one coming.<p>as i commented there: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39054152">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39054152</a><p>noone should ever be able to file a CVE without the product owner having a say in this.<p>filing a CVE should always include the party that is responsible for the vulnerability with proper checks and balances.<p>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.<p>this is pretty much why linus torvalds refused to announce when they fix security issues in the linux kernel.

&quot;No CVEs will be assigned for unfixed security issues in the Linux kernel, assignment will only happen after a fix is available as it can be properly tracked that way by the git commit id of the original fix.&quot;<p>Linus Torvalds: &quot;A bug is a bug.&quot;<p>As a kernel developer of ATM driver, I couldn&#x27;t careless if there is a bug, much less some public authority (t)outing my driver as buggy. They&#x27;ll get fixed, unit-tested, and real-world live-tested for the next release.

Every bugfix in the kernel is now a CVE. That&#x27;s awful.<p>Every unfixed security issue is now no longer assigned a CVE until it&#x27;s fixed. That&#x27;s even worse.

Just in case anybody is wondering if this is significant...think about the implications of tens of thousands of CVE numbers being assigned for every stable kernel patch. There will have to be changes in the ways people are dealing with these.

So because the cve system has a few problems that annoy the kernel developers they decided an appropriate response is to completely sabotage it?<p>Mature, you guys.