[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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[1] 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
[1] 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.
