[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Fri, 18 May 2012 23:52:27 -0500

On Fri, May 18, 2012 at 5:57 PM, William A. Rowe Jr.
<wrowe_at_rowe-clan.net> wrote:
> 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 :)

I think the situation we've had in the past is that stuff we've
decided is "oh, just a defect" downstream has decided is a real
vulnerability. *They* request the CVE, and we're then backpedalling
to ensure the information is properly propagated, and that multiple
downstream vendors haven't requested multiple CVEs. Maybe that's bad
behavior on the part of the downstream users; I don't really know what
the proper protocol is here.

There will always be a grey area in that one person's defect is
another person's vulnerability. The question is whether or not we
should be liberal about requesting CVEs in the cases where a defect
*might* be considered a vulnerability, rather than limiting ourselves
solely to issues which have demonstrable vulnerability-like effects.


uberSVN: Apache Subversion Made Easy
Received on 2012-05-19 06:53:06 CEST

This is an archived mail posted to the Subversion Dev mailing list.