On 5/18/2012 11:57 AM, Greg Stein wrote:
> On Thu, May 17, 2012 at 2:02 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> ...
>> CVE are meant to be a unique identifier to an issue so I think it's
>> a (minor?) problem if different downstreamers requests CVE's
>> independently.
>> ...
>> IOW, "Should we be trigger-happy or conservative on requesting CVE
>> identifiers?".
>
> I think we can be conservative on this. We track things using issues,
> version control, and mailing lists. The CVE doesn't really help *us*.
>
> If we believe that a downstream user is going to want/need some fancy
> footwork around a security problem, then I think we generate a CVE
> (for their tracking) and begin the private disclosure process.
>
> Security team: does this sound like a reasonable approach?
Not really.
As a community we rely on certain words and phrases to mean specific things, and
to not mean other things. Using a CVE, once an advisory is likely to be filed,
ensures that every vendor, open source project and os distributor are all speaking
about the exact same defect.
The Apache httpd and tomcat projects have found them invaluable to keep confusion
down to a dull roar.
Just don't be allocating CVE's if you don't plan to treat a fix as a vulnerability.
If it is 'just a defect' it shouldn't be assigned a CVE. Don't recycle a CVE that
describes a different problem or code defect. And communicate that CVE as early
as possible before the public is aware of the defect so it doesn't grow multiple
identifiers as different parties react to the same issue.
It doesn't matter so much if we assign the CVE, or the reporter assigns one for us
(provided they *communicate it* to us, and visa versa if we allocate one :)
Received on 2012-05-19 00:57:29 CEST