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.
-----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 -
/subversion/site/publish/docs/release-notes/release-history.html
-----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
view.
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).
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPuRKUAAoJEBDAHFovYFnnF9QP/AutoeJNM1EJNvvH9jPQRJsn
FFC4Gb1FIIpllAtiK8D6mWvuo4Qh1COQ6PJrm7OwlnMaiTY3DcGzwQ7KjGGTMH0x
NrgJnXzZfnyshVWMxZM9sVmGJHz733IOrkM8yHcTJwt2Fk+/tA+l1SUCso8r/rFm
gyMxfunNpF+sQw1o2jap/FB00xyfMjUOUl5EvIn/SIPdAvO5g6vQMfl5H1FSZXDQ
rNLuK+KnP9NM917ILIdSCy/+qyRbQ3phyq1wOTDdsB2w5xsXHKWRvgCVH8A7XFtw
rGIlxmMktsLbEJisBrzVwvLVJ9cri/m8Vha+E48XY3J4CpPNrWcnrKl/EDotyL3a
/9hXPSaiDBqF/ubx7gEOJPYnxXH5rPF68fuEI23vjXCum3EhbdbaMmVbkAN7Eb0A
g+rTNfiDclbDLHe4brNeNUEx83V/Wrmfq4fvDH4puP5fn+oOatPERweCzwRmZ/1c
EXDteXBOsyN2RqzRUtAwGfJ3lKCj6+qDsf9rTke1ha+PwA7J2YrASlQSCE39fLHe
xyRW31QUBhZaVpRbE3cVKRMdJBW8DK/IF9Xiz5UlmRtMgfR1IVinXPjkJtjKaWcH
QvK84XXzMiWoLSwaWQsvmpsqi1s7roxtSzIZaq2azTx2dtohrGZlcXP5lZ+S2BT4
iD9AxIYduZ7+CLIZzis2
=vudS
-----END PGP SIGNATURE-----
Received on 2012-05-21 01:58:40 CEST