Date: Sat, 30 May 2015 00:36:19 +0300 From: Henri Salo <henri@...v.fi> To: Greg KH <greg@...ah.com> Cc: oss-security@...ts.openwall.com, cve-assign@...re.org Subject: Re: CVE request: vulnerability in the kernel tty subsystem. Please correct me if I am wrong somewhere in this email. I just want to understand why you said this. On Tue, May 26, 2015 at 07:52:47AM -0700, Greg KH wrote: > For a 2 year old bugfix? Age does not matter for CVE assigment as far as I can tell. > I know you all like to try to track bugs for old and obsolete products, > but really, there's no end of CVEs you could request if you wish to do > this. Heck, I could start asking for multiple CVEs for every single > stable kernel release I do, which would just be pointless. > Please just mark this as a "oh look, a bug was fixed years ago and we > need to backport it because we have old kernels out in the wild and our > customers don't like to upgrade" type issue. > Don't force CVEs to play by the odd enterprise rules that you all wish > perpetuate. CVE is defined as "common identifiers for publicly known information-security vulnerabilities in publicly released software packages". How is it pointless to request CVE identifier for security issue in kernel or other software if that software is released and used by some distro or other entity? How do you calculate how many users are using some kernel if it is released in public website? Please note that this might be easier for kernel than some other software like web-application project in GitHub. One reason I could think of for not requesting CVEs for issues is that it creates workload to MITRE or other CNA (and in some cases users of CVE when they are tracking issues). If that is the case could you or MITRE tell me where should that line be drawn? Or if this is not the case do you mean that "vulnerability in the kernel tty subsystem" is not critical enough for CVE? If that is the case how is that calculated? Or even "vulnerability in the kernel tty subsystem" is not a security issue? -- Henri Salo
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ