[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130423082605.GM5828@dhcp-25-225.brq.redhat.com>
Date: Tue, 23 Apr 2013 10:26:06 +0200
From: Petr Matousek <pmatouse@...hat.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: Re: Linux kernel: more net info leak fixes for
v3.9
On Mon, Apr 22, 2013 at 11:02:10AM -0700, Greg KH wrote:
> 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.
I agree with Greg. We (Red Hat) haven't requested CVEs for issues in -rc
releases, which we consider under development, in the past and we do not
intend to start doing that. It's in fact one of the criteria when
examining upstream commits - if the bug and the fix is in -rc release,
skip it.
Just my 2 cents.
--
Petr Matousek / Red Hat Security Response Team
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.
