One can go around in circles with arguments about what is a "known possible security bug" vs "bug with unknown security implications". To add to the hyperbole one could also ask what does it take to become a "security issue" (e.g. is a bug that causes a crash/lock-up but otherwise doesn't provide root access a security issue? One may shrug off a lock-up on a personal laptop, but many clients will be very annoyed with lock-ups on servers running essential services).
Personally I'd like to know whether a kernel upgrade fixes a "known possible security bug", where the bug can be triggered by a deliberate and remote attack. However, one can also suspect that a reason for the rather obfuscated security warnings by Greg KH et al (i.e. "strongly encouraged to upgrade") is not the definition of a security issue, but the politics of the Linux Foundation. Once a bug has a CVE number, the count of security issues in Linux goes up. Obviously it's very useful for marketing reasons if the number of security issues in Linux is lower than other systems. Hence why add to the count of security bugs (even though they may lack CVEs), through kernel update disclosures ?
Posted Nov 10, 2008 7:21 UTC (Mon) by nix (subscriber, #2304)
[Link]
My understanding was more 'once a bug has a CVE number, really annoying
embargo rules come into play, with the result that many people would
rather rip off their own legs than try to get a CVE number assigned'.
what security fix?
Posted Nov 10, 2008 8:12 UTC (Mon) by PaXTeam (subscriber, #24616)
[Link]
asking for a CVE is independent of asking for an embargo. one does the latter out of courtesy to distros or to please the corporate bosses (say, if one's employed by one of the commercial distros), but otherwise there's nothing that would force anyone to observe any embargo. so yes, those arguments have always been bogus too.