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
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-----
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
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 01:58:40 CEST