Date: Mon, 22 Apr 2013 11:02:10 -0700 From: Greg KH <greg@...ah.com> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com Subject: Re: Re: Linux kernel: more net info leak fixes for v3.9 On Mon, Apr 22, 2013 at 01:43:17PM -0400, cve-assign@...re.org wrote: > >On Mon, Apr 22, 2013 at 01:44:17AM -0400, cve-assign@...re.org wrote: > >> 680d04e0ba7e926233e3b9cee59125ce181f66ba CVE-2013-3236 > >> d5e0d0f607a7a029c6563a0470d88255c89a8d11 CVE-2013-3237 > > > >Please explain how these can get a CVE number when the code involved has > >never even been in a kernel.org release yet? > > MITRE has never had any restrictions on CVEs for issues that exist > only in release-candidate software or only in beta software. See for > example "Attendees agreed that CVE should include problems in beta > software, provided that the beta code was intended for public > dissemination" in the > http://cve.mitre.org/data/board/archives/2000-03/msg00007.html post. > > These CVEs tend to be rare, possibly because they are useful to fewer > people. Recent examples in which a major vendor specifically chose to > assign a CVE name to an issue affecting only beta software are: > > CVE-2009-2968 - VMware Studio 2.0 public beta > > CVE-2010-0113 - Symantec Norton Mobile Security 1.0 Beta > > A few months ago, MITRE started to draft some rough guidelines for a > case of a vendor who was considering use of CVEs during beta testing. > That case seems mostly inapplicable to the current question > (CVE-2013-3236, CVE-2013-3237, etc. weren't in any sense based on > "vendor" requests), but we might be able to share guidelines at some > point if any vendor here is in a similar position. Thanks for the explanation, but, given the rate-of-churn in the Linux kernel -rc releases, I would be really wary to start wanting to assign CVEs to things that only show up in these types of kernel releases. Unless you really want to be swamped with requests, it's your choice :) Linux kernel -rc releases are for developers, and for those people wanting to help with Linux kernel development, they are not for anyone to run on any system that they do not to expect to immediately explode into a bunch of pieces, let alone expect to be "perfect" from a security standpoint. These releases are much different from the two closed-source products you list above, which are not developed in the open, and rely on "public beta" releases to do some of their testing on real-world systems. As the Linux kernel is developed entirely in the open, starting to want to assign CVE entries to issues that show up in one -rc release, and are fixed before the final kernel release, seems a bit odd. But hey, it's your system, not mine, good luck. greg k-h  You do realize just how fast it is, right? Faster than you can ever imagine, or even want to think about, and almost impossible to keep up with.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.