That's my point. The question is which fraction of users/businesses actually ever ask for support? And as long as error can be replicated on an activated install, I guess they could still get support.
I knew a number of companies who were using a handful of RedHat servers and many more running CentOS and whenever they encountered issues on a CentOS system they would just replicate it on a RedHat one before asking for support and sending logs. Morally dubious but contractually OK.
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.
