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/ ? Daniel > -----Original message----- > From: Mark Thomas <ma...@apache.org> > To: Hyrum K Wright <hyrum.wri...@wandisco.com>, "William A. Rowe Jr." > <wr...@rowe-clan.net>, secur...@apache.org, dev@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----- >
