Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 19 Mar 2012 15:45:18 +0100
From: Andreas Ericsson <>
To: Kurt Seifried <>
CC: "" <>
Subject: Re: CVE Requests

On 03/16/2012 06:42 PM, Kurt Seifried wrote:
> On 03/16/2012 04:26 AM, Andreas Ericsson wrote:
>> On 03/16/2012 04:41 AM, Kurt Seifried wrote:
>>> I need the actual info, please refer to:
>> Those mails are all exemplary requests for CVE id's, ofcourse, but the
>> fact that they are all already fixed and released means that 100% of
>> the work is already done. At that point, assigning a CVE id is mostly
>> useless and is done as a "just for the record" thing.
> Uh no. Tracking these issues is critical and it happens across dozens,
> and in some cases hundreds of vendors (e.g. CVE-2009-3555).

Which is why it's handy to be able to use an ID when discussing the fix
as well. Googling for the discussion becomes all but impossible otherwise,
since you're reduced to, in your own words, "that openssl thing".

>> The need for unified identifier for a particular issue is greatest
>> when discussing the problem and its potential solutions; Not how
>> someone actually solved it after it's already done. If CVE is to become
>> a thing for changelogs only, all those projects that don't use one
>> but rely on commit-messages instead won't use CVE id's at all, and the
>> usefulness of the CVE database dwindles.
> If only it were that simple. Having worked for iSIGHT/iDefense prior to
> Red Hat, and now at Red Hat, let me say this simply:
> CVE Is 100% critical for security work at large scales.
> Automated products/etc need reliable names for security issues.
> Customers need reliable ways to ask questions (did you fix that OpenSSL
> thing mentioned over in this random blog post? Oh you mean this CVE,
> yes. etc.).

Yes, but that question becomes very hard to answer when it's not
written down what CVE it was that was fixed, which is why I think it's
crucial to be able to get one before the fix is available. Many small
projects don't use changelogs or track issues all that carefully after
they're fixed, but rely entirely on commit messages to keep (and give)
such information to its users.

Then again, I'm speaking from a developer standpoint and I generally
need (well, want, but for the sake of issue history I should say
"strongly prefer to have") the id long before most users even know
there's a problem.

By this thread I'm fairly assured that won't be a problem though, so
I'll refrain from commenting further.

Thanks to all who clarified.

Andreas Ericsson         
OP5 AB                   
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

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.