Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3ad7ddd3dd47f85989a54dfe03c8aac@chewa.net>
Date: Tue, 11 Nov 2008 09:13:33 +0100
From: Rémi Denis-Courmont <rem@...eolan.org>
To: "Steven M. Christey" <coley@...us.mitre.org>
Cc: Nico Golde <oss-security+ml@...lde.de>, oss-security@...ts.openwall.com, 
 coley@...re.org
Subject: Re: CVE id request: vlc


   Hello,

On Mon, 10 Nov 2008 16:27:00 -0500 (EST), "Steven M. Christey"
<coley@...us.mitre.org> wrote:
> The information we had available at the time of request didn't suggest
> different versions being affected.  For example, the upstream advisory
> doesn't mention anything about different versions, and both Tobias Klein
> advisories say "VLC media player < 0.9.6".

CUE: 0.5.0 - 0.9.5 (as per http://www.videolan.org/security/sa0810.html)
RealText: 0.9.0 - 0.9.5

0.9.* is the only supported version from videolan.org anyway.

> So at the time of assignment, Best Available Information (the cornerstone
> of CVE analysis) was that they were the same type of issue affecting the
> same versions.

> This is becoming a big problem for us in CVE - requests to oss-security
> are coming in without the kind of information that we rely on heavily to
> decide when we have one CVE or multiple CVE's.  Compared to last year,
the
> requests are coming in when the information's less mature, *and* public.

CVE.mitre.org says nothing about vendor obtaining a CVE number, only
researchers. And typically, these guys don't do it, when dealing with
videolan.org anyway.

Also consider our project structure: We have a large code base with lots of
legacy, so lots of bugs. We have a large user base, so we're an attractive
target. We have had very few security analysis until recently, so there is
a lot more CVEs to come by any chance. We're almost entirely run by loosely
coordinated volunteers (including myself) so you cannot expect much more
dedication. And we are hardly supported by distributions (basically only
Debian and Gentoo), such that almost nobody will care on vendor-sec.

Now I am happy to adapt our security handling process a bit, if MITRE,
Debian or whatever other involved party wants. But I am still waiting for
clear guidelines.

N.B.: I am not subscribed to this mailing list

-- 
Rémi Denis-Courmont

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.