Comment by staticassertion
4 days ago
> I think the most practical reason not to flag which bugs are security bugs is to avoid helping blackhat hackers by painting a giant neon sign and that should be more than enough.
It doesn't work. I've looked at the kernel commit log and found vulnerabilities that aren't announced/ marked. Attackers know how to do this. Not announcing is a pure negative.
Linus argument against labeling some bugs, or even lack of features, as security vulnerabilities, is that all bugs can, with enough work and together with other circumstances, be a security vulnerability. Essentially every commit would need to be labeled as a cve fix, and then it’s just extra work for nothing.
> Linus argument against labeling some bugs, or even lack of features, as security vulnerabilities, is that all bugs can, with enough work and together with other circumstances, be a security vulnerability.
This isn't true though. Some bugs are not exploitable, some are trivial to exploit. Even if sometimes we'd end up with a DoS that was actually a privesc, how does that make it pointless to label the ones we know are privescs as such?
You can argue "oh no sometimes we mislabeled a DoS" but most of the time you can tell when something is going to be a powerful vuln or not ahead of time, I think this is a red herring to optimize around.
> Essentially every commit would need to be labeled as a cve fix, and then it’s just extra work for nothing.
This isn't true and has never been true for any other project. There are issues with the CVE system, this is not one of them. Note that the Linux kernel is the standout here - we don't have to guess about issues in the CVE system, we observe them all the time. "We need a CVE for every commit" is not one of them.