[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Thu, 17 May 2012 12:59:23 -0500

On Thu, May 17, 2012 at 12:51 PM, Julian Foad
<julianfoad_at_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?


uberSVN: Apache Subversion Made Easy
Received on 2012-05-17 19:59:55 CEST

This is an archived mail posted to the Subversion Dev mailing list.