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 <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 19:46:19 CEST