William A Rowe Jr wrote on Sun, May 20, 2012 at 18:51:36 -0500:
> And when you truly can't define an abuse case, but a third party has
> insisted on allocating a cve, you should post a refutation to the dev
> list asking to be shown otherwise and clearly stating your
> counterargument ... and have security@ post a link to that post as the
> 'vendor response' to that particular cve.
Sounds like this information would be useful on www.a.o/security/ ?
> -----Original message-----
> From: Mark Thomas <markt_at_apache.org>
> To: Hyrum K Wright <hyrum.wright_at_wandisco.com>, "William A. Rowe Jr."
> <wrowe_at_rowe-clan.net>, security_at_apache.org, dev_at_subversion.apache.org
> Sent: Sun, May 20, 2012 15:49:56 GMT+00:00
> Subject: Re: svn commit: r1339559 -
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 20/05/2012 15:13, Stefan Sperling wrote:
>> 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.
> If it is a security issue, then it requires a CVE regardless of
> severity. It is the vulnerability announcement that should inform
> users of the severity.
> There are plenty of cases where authenticated users aren't considered
> trusted users.
> There are also plenty of cases where the project may consider
> something a non-issue while the reporter of the issue has a different
> To re-iterate, if there is a valid use case for the software where an
> issue triggers some form of vulnerability - regardless of the severity
> - - then it should be treated as a vulnerability and assigned a CVE. The
> vulnerability report can make clear any limits to the circumstances
> associated with the vulnerability (for example Tomcat has had a number
> of minor vulnerabilities that only apply in a shared hosting environment).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----
Received on 2012-05-21 19:46:19 CEST