You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2012/05/17 19:01:09 UTC
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Should we the term "security" if a release does not have a CVE associated
with it?
On May 17, 2012 7:45 AM, <ph...@apache.org> wrote:
> Author: philip
> Date: Thu May 17 11:44:39 2012
> New Revision: 1339559
>
> URL: http://svn.apache.org/viewvc?rev=1339559&view=rev
> Log:
> * publish/release-notes/release-history.html: Add recent releases.
>
> Modified:
> subversion/site/publish/docs/release-notes/release-history.html
>
> Modified: subversion/site/publish/docs/release-notes/release-history.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/release-history.html?rev=1339559&r1=1339558&r2=1339559&view=diff
>
> ==============================================================================
> --- subversion/site/publish/docs/release-notes/release-history.html
> (original)
> +++ subversion/site/publish/docs/release-notes/release-history.html Thu
> May 17 11:44:39 2012
> @@ -31,6 +31,27 @@ Subversion 2.0.</p>
>
> <ul>
> <li>
> + <b>Subversion 1.7.5</b> (Thursday, 17 May 2012): Bugfix/security
> release.
> + </li>
> + <li>
> + <b>Subversion 1.7.4</b> (Thursday, 8 March 2012): Bugfix/security
> release.
> + </li>
> + <li>
> + <b>Subversion 1.7.3</b> (Monday, 13 February 2012): Bugfix/security
> release.
> + </li>
> + <li>
> + <b>Subversion 1.7.2</b> (Monday, 5 December 2011): Bugfix/security
> release.
> + </li>
> + <li>
> + <b>Subversion 1.7.1</b> (Sunday, 23 October 2011): Bugfix/security
> release.
> + </li>
> + <li>
> + <b>Subversion 1.7.0</b> (Tuesday, 11 October 2011): Feature and
> bugfix release, see the <a href="/docs/release-notes/1.7.html">release
> notes</a>.
> + </li>
> + <li>
> + <b>Subversion 1.6.18</b> (Thursday, 12 April 2012): Bugfix/security
> release.
> + </li>
> + <li>
> <b>Subversion 1.6.17</b> (Wednesday, 1 June 2011): Bugfix/security
> release.
> </li>
> <li>
>
>
>
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Greg Stein <gs...@gmail.com>.
On May 18, 2012 6:57 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>
> On 5/18/2012 11:57 AM, Greg Stein wrote:
> > On Thu, May 17, 2012 at 2:02 PM, Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> >> ...
> >> CVE are meant to be a unique identifier to an issue so I think it's
> >> a (minor?) problem if different downstreamers requests CVE's
> >> independently.
> >> ...
> >> IOW, "Should we be trigger-happy or conservative on requesting CVE
> >> identifiers?".
> >
> > I think we can be conservative on this. We track things using issues,
> > version control, and mailing lists. The CVE doesn't really help *us*.
> >
> > If we believe that a downstream user is going to want/need some fancy
> > footwork around a security problem, then I think we generate a CVE
> > (for their tracking) and begin the private disclosure process.
> >
> > Security team: does this sound like a reasonable approach?
>
> Not really.
I don't understand how your email differs from what I stated.
> As a community we rely on certain words and phrases to mean specific
things, and
> to not mean other things. Using a CVE, once an advisory is likely to be
filed,
> ensures that every vendor, open source project and os distributor are all
speaking
> about the exact same defect.
Right. I said, "If we believe [they need one]... we generate a CVE". Same
thing as "likely to be filed".
>...
> Just don't be allocating CVE's if you don't plan to treat a fix as a
vulnerability.
Right. I said we don't normally set up CVEs. That we be conservative.
So:
> Not really.
What does this mean? What do you suggest we do differently from what I
suggested, and you apparently acknowledged as a reasonable approach?
-g
Re: svn commit: r1339559 -
/subversion/site/publish/docs/release-notes/release-history.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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 <hy...@wandisco.com>, "William A. Rowe Jr."
> <wr...@rowe-clan.net>, security@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-----
>
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <ma...@apache.org>
To: Hyrum K Wright <hy...@wandisco.com>, "William A. Rowe Jr."
<wr...@rowe-clan.net>, security@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-----
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Mark Thomas <ma...@apache.org>.
-----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-----
Re: svn commit: r1339559 -
/subversion/site/publish/docs/release-notes/release-history.html
Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 18, 2012 at 11:52:27PM -0500, Hyrum K Wright wrote:
> I think the situation we've had in the past is that stuff we've
> decided is "oh, just a defect" downstream has decided is a real
> vulnerability. *They* request the CVE, and we're then backpedalling
> to ensure the information is properly propagated, and that multiple
> downstream vendors haven't requested multiple CVEs. Maybe that's bad
> behavior on the part of the downstream users; I don't really know what
> the proper protocol is here.
>
> There will always be a grey area in that one person's defect is
> another person's vulnerability. The question is whether or not we
> should be liberal about requesting CVEs in the cases where a defect
> *might* be considered a vulnerability, rather than limiting ourselves
> solely to issues which have demonstrable vulnerability-like effects.
I think we should request CVEs for issues that put our users' systems
at obvious risk of being compromised and/or misused. Arbitrary code execution
and exposure of sensitive information are issues I deem worth getting a CVE
number and running a special release process for.
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.
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Fri, May 18, 2012 at 5:57 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/18/2012 11:57 AM, Greg Stein wrote:
>> On Thu, May 17, 2012 at 2:02 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> ...
>>> CVE are meant to be a unique identifier to an issue so I think it's
>>> a (minor?) problem if different downstreamers requests CVE's
>>> independently.
>>> ...
>>> IOW, "Should we be trigger-happy or conservative on requesting CVE
>>> identifiers?".
>>
>> I think we can be conservative on this. We track things using issues,
>> version control, and mailing lists. The CVE doesn't really help *us*.
>>
>> If we believe that a downstream user is going to want/need some fancy
>> footwork around a security problem, then I think we generate a CVE
>> (for their tracking) and begin the private disclosure process.
>>
>> Security team: does this sound like a reasonable approach?
>
> Not really.
>
> As a community we rely on certain words and phrases to mean specific things, and
> to not mean other things. Using a CVE, once an advisory is likely to be filed,
> ensures that every vendor, open source project and os distributor are all speaking
> about the exact same defect.
>
> The Apache httpd and tomcat projects have found them invaluable to keep confusion
> down to a dull roar.
>
> Just don't be allocating CVE's if you don't plan to treat a fix as a vulnerability.
> If it is 'just a defect' it shouldn't be assigned a CVE. Don't recycle a CVE that
> describes a different problem or code defect. And communicate that CVE as early
> as possible before the public is aware of the defect so it doesn't grow multiple
> identifiers as different parties react to the same issue.
>
> It doesn't matter so much if we assign the CVE, or the reporter assigns one for us
> (provided they *communicate it* to us, and visa versa if we allocate one :)
I think the situation we've had in the past is that stuff we've
decided is "oh, just a defect" downstream has decided is a real
vulnerability. *They* request the CVE, and we're then backpedalling
to ensure the information is properly propagated, and that multiple
downstream vendors haven't requested multiple CVEs. Maybe that's bad
behavior on the part of the downstream users; I don't really know what
the proper protocol is here.
There will always be a grey area in that one person's defect is
another person's vulnerability. The question is whether or not we
should be liberal about requesting CVEs in the cases where a defect
*might* be considered a vulnerability, rather than limiting ourselves
solely to issues which have demonstrable vulnerability-like effects.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/18/2012 11:57 AM, Greg Stein wrote:
> On Thu, May 17, 2012 at 2:02 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> ...
>> CVE are meant to be a unique identifier to an issue so I think it's
>> a (minor?) problem if different downstreamers requests CVE's
>> independently.
>> ...
>> IOW, "Should we be trigger-happy or conservative on requesting CVE
>> identifiers?".
>
> I think we can be conservative on this. We track things using issues,
> version control, and mailing lists. The CVE doesn't really help *us*.
>
> If we believe that a downstream user is going to want/need some fancy
> footwork around a security problem, then I think we generate a CVE
> (for their tracking) and begin the private disclosure process.
>
> Security team: does this sound like a reasonable approach?
Not really.
As a community we rely on certain words and phrases to mean specific things, and
to not mean other things. Using a CVE, once an advisory is likely to be filed,
ensures that every vendor, open source project and os distributor are all speaking
about the exact same defect.
The Apache httpd and tomcat projects have found them invaluable to keep confusion
down to a dull roar.
Just don't be allocating CVE's if you don't plan to treat a fix as a vulnerability.
If it is 'just a defect' it shouldn't be assigned a CVE. Don't recycle a CVE that
describes a different problem or code defect. And communicate that CVE as early
as possible before the public is aware of the defect so it doesn't grow multiple
identifiers as different parties react to the same issue.
It doesn't matter so much if we assign the CVE, or the reporter assigns one for us
(provided they *communicate it* to us, and visa versa if we allocate one :)
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Greg Stein <gs...@gmail.com>.
On Thu, May 17, 2012 at 2:02 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>...
> CVE are meant to be a unique identifier to an issue so I think it's
> a (minor?) problem if different downstreamers requests CVE's
> independently.
>...
> IOW, "Should we be trigger-happy or conservative on requesting CVE
> identifiers?".
I think we can be conservative on this. We track things using issues,
version control, and mailing lists. The CVE doesn't really help *us*.
If we believe that a downstream user is going to want/need some fancy
footwork around a security problem, then I think we generate a CVE
(for their tracking) and begin the private disclosure process.
Security team: does this sound like a reasonable approach?
Cheers,
-g
Re: svn commit: r1339559 -
/subversion/site/publish/docs/release-notes/release-history.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Hyrum K Wright wrote on Thu, May 17, 2012 at 12:59:23 -0500:
> I'lll also point out that in the past downstream users have made the
> determination for us, and requested their own CVEs for issues in our
> releases. I don't think that's a problem, and we can't really control
> how downstream judges the impact of a particular issue, but it just
> feels nice if we handle the CVE process for our own issues.
>
CVE are meant to be a unique identifier to an issue so I think it's
a (minor?) problem if different downstreamers requests CVE's
independently.
> In the past CVE almost exclusively meant an embargo and
> pre-notification and the rest of the circus that implies. I think
> there is some middle ground here where we request a CVE, but then just
> treat the release in a standard way, just mentioning the CVE in
> CHANGES or the release announcement.
>
> It might also be nice to look at how other projects handle this stuff.
> Are they as aggressive about labeling things "security-related" and
> getting CVEs as we are?
IOW, "Should we be trigger-happy or conservative on requesting CVE
identifiers?".
I think that's a good question; perhaps we should ask it security@.
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Thu, May 17, 2012 at 12:51 PM, Julian Foad
<ju...@btopenworld.com> wrote:
> Philip Martin wrote:
>> 1.7.5 includes r1298343 a server SEGV that can only be triggered by
>> those with commit access. We never bothered getting a CVE for
>> that. Does that mean we can't call it a security release?
>
> What's the point in having two different definitions of the term "security"? I don't know about our historical practice, but if we can decide from now on that a "security release" means a "security issue" was fixed, and a "security issue" means something that we decided was worth getting a CVE for, that would seem to be a recipe for less confusion.
I'lll also point out that in the past downstream users have made the
determination for us, and requested their own CVEs for issues in our
releases. I don't think that's a problem, and we can't really control
how downstream judges the impact of a particular issue, but it just
feels nice if we handle the CVE process for our own issues.
In the past CVE almost exclusively meant an embargo and
pre-notification and the rest of the circus that implies. I think
there is some middle ground here where we request a CVE, but then just
treat the release in a standard way, just mentioning the CVE in
CHANGES or the release announcement.
It might also be nice to look at how other projects handle this stuff.
Are they as aggressive about labeling things "security-related" and
getting CVEs as we are?
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> 1.7.5 includes r1298343 a server SEGV that can only be triggered by
> those with commit access. We never bothered getting a CVE for
> that. Does that mean we can't call it a security release?
What's the point in having two different definitions of the term "security"? I don't know about our historical practice, but if we can decide from now on that a "security release" means a "security issue" was fixed, and a "security issue" means something that we decided was worth getting a CVE for, that would seem to be a recipe for less confusion.
- Julian
> Greg Stein <gs...@gmail.com> writes:
>
>> Should we the term "security" if a release does not have a CVE
> associated
>> with it?
>> On May 17, 2012 7:45 AM, <ph...@apache.org> wrote:
>>
>>> Author: philip
>>> Date: Thu May 17 11:44:39 2012
>>> New Revision: 1339559
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1339559&view=rev
>>> Log:
>>> * publish/release-notes/release-history.html: Add recent releases.
>>>
>>> Modified:
>>> subversion/site/publish/docs/release-notes/release-history.html
>>>
>>> Modified:
> subversion/site/publish/docs/release-notes/release-history.html
>>> URL:
>>>
> http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/release-history.html?rev=1339559&r1=1339558&r2=1339559&view=diff
>>>
>>>
> ==============================================================================
>>> --- subversion/site/publish/docs/release-notes/release-history.html
>>> (original)
>>> +++ subversion/site/publish/docs/release-notes/release-history.html Thu
>>> May 17 11:44:39 2012
>>> @@ -31,6 +31,27 @@ Subversion 2.0.</p>
>>>
>>> <ul>
>>> <li>
>>> + <b>Subversion 1.7.5</b> (Thursday, 17 May 2012):
> Bugfix/security
>>> release.
>>> + </li>
>>> + <li>
>>> + <b>Subversion 1.7.4</b> (Thursday, 8 March 2012):
> Bugfix/security
>>> release.
>>> + </li>
>>> + <li>
>>> + <b>Subversion 1.7.3</b> (Monday, 13 February 2012):
> Bugfix/security
>>> release.
>>> + </li>
>>> + <li>
>>> + <b>Subversion 1.7.2</b> (Monday, 5 December 2011):
> Bugfix/security
>>> release.
>>> + </li>
>>> + <li>
>>> + <b>Subversion 1.7.1</b> (Sunday, 23 October 2011):
> Bugfix/security
>>> release.
>>> + </li>
>>> + <li>
>>> + <b>Subversion 1.7.0</b> (Tuesday, 11 October 2011):
> Feature and
>>> bugfix release, see the <a
> href="/docs/release-notes/1.7.html">release
>>> notes</a>.
>>> + </li>
>>> + <li>
>>> + <b>Subversion 1.6.18</b> (Thursday, 12 April 2012):
> Bugfix/security
>>> release.
>>> + </li>
>>> + <li>
>>> <b>Subversion 1.6.17</b> (Wednesday, 1 June 2011):
> Bugfix/security
>>> release.
>>> </li>
>>> <li>
>>>
>>>
>>>
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>
Re: svn commit: r1339559 -
/subversion/site/publish/docs/release-notes/release-history.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Thu, May 17, 2012 at 13:50:55 -0400:
> Dunno. Probably for that one, yeah. I just took a quick look at 1.7.1 and
> 1.7.2 and nothing jumped out.
so +1 on s/security// for them
> On May 17, 2012 1:31 PM, "Philip Martin" <ph...@wandisco.com>
> wrote:
>
> > 1.7.5 includes r1298343 a server SEGV that can only be triggered by
> > those with commit access. We never bothered getting a CVE for
> > that. Does that mean we can't call it a security release?
> >
> > Greg Stein <gs...@gmail.com> writes:
> >
> > > Should we the term "security" if a release does not have a CVE associated
> > > with it?
> > > On May 17, 2012 7:45 AM, <ph...@apache.org> wrote:
> > >
> > >> Author: philip
> > >> Date: Thu May 17 11:44:39 2012
> > >> New Revision: 1339559
> > >>
> > >> URL: http://svn.apache.org/viewvc?rev=1339559&view=rev
> > >> Log:
> > >> * publish/release-notes/release-history.html: Add recent releases.
> > >>
> > >> Modified:
> > >> subversion/site/publish/docs/release-notes/release-history.html
> > >>
> > >> Modified:
> > subversion/site/publish/docs/release-notes/release-history.html
> > >> URL:
> > >>
> > http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/release-history.html?rev=1339559&r1=1339558&r2=1339559&view=diff
> > >>
> > >>
> > ==============================================================================
> > >> --- subversion/site/publish/docs/release-notes/release-history.html
> > >> (original)
> > >> +++ subversion/site/publish/docs/release-notes/release-history.html Thu
> > >> May 17 11:44:39 2012
> > >> @@ -31,6 +31,27 @@ Subversion 2.0.</p>
> > >>
> > >> <ul>
> > >> <li>
> > >> + <b>Subversion 1.7.5</b> (Thursday, 17 May 2012): Bugfix/security
> > >> release.
> > >> + </li>
> > >> + <li>
> > >> + <b>Subversion 1.7.4</b> (Thursday, 8 March 2012): Bugfix/security
> > >> release.
> > >> + </li>
> > >> + <li>
> > >> + <b>Subversion 1.7.3</b> (Monday, 13 February 2012): Bugfix/security
> > >> release.
> > >> + </li>
> > >> + <li>
> > >> + <b>Subversion 1.7.2</b> (Monday, 5 December 2011): Bugfix/security
> > >> release.
> > >> + </li>
> > >> + <li>
> > >> + <b>Subversion 1.7.1</b> (Sunday, 23 October 2011): Bugfix/security
> > >> release.
> > >> + </li>
> > >> + <li>
> > >> + <b>Subversion 1.7.0</b> (Tuesday, 11 October 2011): Feature and
> > >> bugfix release, see the <a href="/docs/release-notes/1.7.html">release
> > >> notes</a>.
> > >> + </li>
> > >> + <li>
> > >> + <b>Subversion 1.6.18</b> (Thursday, 12 April 2012): Bugfix/security
> > >> release.
> > >> + </li>
> > >> + <li>
> > >> <b>Subversion 1.6.17</b> (Wednesday, 1 June 2011): Bugfix/security
> > >> release.
> > >> </li>
> > >> <li>
> > >>
> > >>
> > >>
> >
> > --
> > uberSVN: Apache Subversion Made Easy
> > http://www.uberSVN.com
> >
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Greg Stein <gs...@gmail.com>.
Dunno. Probably for that one, yeah. I just took a quick look at 1.7.1 and
1.7.2 and nothing jumped out.
On May 17, 2012 1:31 PM, "Philip Martin" <ph...@wandisco.com>
wrote:
> 1.7.5 includes r1298343 a server SEGV that can only be triggered by
> those with commit access. We never bothered getting a CVE for
> that. Does that mean we can't call it a security release?
>
> Greg Stein <gs...@gmail.com> writes:
>
> > Should we the term "security" if a release does not have a CVE associated
> > with it?
> > On May 17, 2012 7:45 AM, <ph...@apache.org> wrote:
> >
> >> Author: philip
> >> Date: Thu May 17 11:44:39 2012
> >> New Revision: 1339559
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1339559&view=rev
> >> Log:
> >> * publish/release-notes/release-history.html: Add recent releases.
> >>
> >> Modified:
> >> subversion/site/publish/docs/release-notes/release-history.html
> >>
> >> Modified:
> subversion/site/publish/docs/release-notes/release-history.html
> >> URL:
> >>
> http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/release-history.html?rev=1339559&r1=1339558&r2=1339559&view=diff
> >>
> >>
> ==============================================================================
> >> --- subversion/site/publish/docs/release-notes/release-history.html
> >> (original)
> >> +++ subversion/site/publish/docs/release-notes/release-history.html Thu
> >> May 17 11:44:39 2012
> >> @@ -31,6 +31,27 @@ Subversion 2.0.</p>
> >>
> >> <ul>
> >> <li>
> >> + <b>Subversion 1.7.5</b> (Thursday, 17 May 2012): Bugfix/security
> >> release.
> >> + </li>
> >> + <li>
> >> + <b>Subversion 1.7.4</b> (Thursday, 8 March 2012): Bugfix/security
> >> release.
> >> + </li>
> >> + <li>
> >> + <b>Subversion 1.7.3</b> (Monday, 13 February 2012): Bugfix/security
> >> release.
> >> + </li>
> >> + <li>
> >> + <b>Subversion 1.7.2</b> (Monday, 5 December 2011): Bugfix/security
> >> release.
> >> + </li>
> >> + <li>
> >> + <b>Subversion 1.7.1</b> (Sunday, 23 October 2011): Bugfix/security
> >> release.
> >> + </li>
> >> + <li>
> >> + <b>Subversion 1.7.0</b> (Tuesday, 11 October 2011): Feature and
> >> bugfix release, see the <a href="/docs/release-notes/1.7.html">release
> >> notes</a>.
> >> + </li>
> >> + <li>
> >> + <b>Subversion 1.6.18</b> (Thursday, 12 April 2012): Bugfix/security
> >> release.
> >> + </li>
> >> + <li>
> >> <b>Subversion 1.6.17</b> (Wednesday, 1 June 2011): Bugfix/security
> >> release.
> >> </li>
> >> <li>
> >>
> >>
> >>
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>
Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html
Posted by Philip Martin <ph...@wandisco.com>.
1.7.5 includes r1298343 a server SEGV that can only be triggered by
those with commit access. We never bothered getting a CVE for
that. Does that mean we can't call it a security release?
Greg Stein <gs...@gmail.com> writes:
> Should we the term "security" if a release does not have a CVE associated
> with it?
> On May 17, 2012 7:45 AM, <ph...@apache.org> wrote:
>
>> Author: philip
>> Date: Thu May 17 11:44:39 2012
>> New Revision: 1339559
>>
>> URL: http://svn.apache.org/viewvc?rev=1339559&view=rev
>> Log:
>> * publish/release-notes/release-history.html: Add recent releases.
>>
>> Modified:
>> subversion/site/publish/docs/release-notes/release-history.html
>>
>> Modified: subversion/site/publish/docs/release-notes/release-history.html
>> URL:
>> http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/release-history.html?rev=1339559&r1=1339558&r2=1339559&view=diff
>>
>> ==============================================================================
>> --- subversion/site/publish/docs/release-notes/release-history.html
>> (original)
>> +++ subversion/site/publish/docs/release-notes/release-history.html Thu
>> May 17 11:44:39 2012
>> @@ -31,6 +31,27 @@ Subversion 2.0.</p>
>>
>> <ul>
>> <li>
>> + <b>Subversion 1.7.5</b> (Thursday, 17 May 2012): Bugfix/security
>> release.
>> + </li>
>> + <li>
>> + <b>Subversion 1.7.4</b> (Thursday, 8 March 2012): Bugfix/security
>> release.
>> + </li>
>> + <li>
>> + <b>Subversion 1.7.3</b> (Monday, 13 February 2012): Bugfix/security
>> release.
>> + </li>
>> + <li>
>> + <b>Subversion 1.7.2</b> (Monday, 5 December 2011): Bugfix/security
>> release.
>> + </li>
>> + <li>
>> + <b>Subversion 1.7.1</b> (Sunday, 23 October 2011): Bugfix/security
>> release.
>> + </li>
>> + <li>
>> + <b>Subversion 1.7.0</b> (Tuesday, 11 October 2011): Feature and
>> bugfix release, see the <a href="/docs/release-notes/1.7.html">release
>> notes</a>.
>> + </li>
>> + <li>
>> + <b>Subversion 1.6.18</b> (Thursday, 12 April 2012): Bugfix/security
>> release.
>> + </li>
>> + <li>
>> <b>Subversion 1.6.17</b> (Wednesday, 1 June 2011): Bugfix/security
>> release.
>> </li>
>> <li>
>>
>>
>>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com