[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: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 20 May 2012 16:13:27 +0200

On Fri, May 18, 2012 at 11:52:27PM -0500, Hyrum K Wright wrote:
> 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.

I think we should request CVEs for issues that put our users' systems
at obvious risk of being compromised and/or misused. Arbitrary code execution
and exposure of sensitive information are issues I deem worth getting a CVE
number and running a special release process for.

A bug in the server that can be used by *authenticated* users to crash a
server child process or thread which will immediately respawn is not as
severe. While it does affect system reliability we do not have to waive
a big red flag at all our users because the possible amount of damage is
relatively low.

Of course, the above is my own opinion and there are cases in the
project's history where a CVE was assigned to problems in the "less
severe" class. And maybe the ASF security team has a different opinion.
Received on 2012-05-20 16:15:45 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.