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

Re: Security release procedures

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 28 Aug 2019 14:07:29 +0200

On Wed, Aug 28, 2019 at 12:41:45PM +0100, Julian Foad wrote:
> This is not just theoretical. The next security issue has already landed in
> the queue and is currently waiting to be fixed and we have not enough hands
> on deck to deal with it.
> https://www.apache.org/security/committers
> After dealing with the last pair of security fixes, I feel following that
> process doesn't give enough value for the extra time and effort it takes,
> for cases that are not looking like a very high severity.
> What could we reduce or eliminate from the process? Especially in the
> private phase, as in the public phase we can more easily involve a wider
> base of volunteers.
> * Drop the CVE? (steps 8, 15, 16)
> For cases that are not looking like a very high severity, we could omit
> the CVE process and much of the formal description associated with it. CVEs
> are a Good Thing, but they do require extra effort and we don't have to do
> that for every vulnerability.


> Instead, on a case by case basis, we could choose to omit the CVE (even
> drop it after initially requesting one) and summarize the issue at a lesser
> level of detail.

Yes. I would be in favour of this.

> * Drop the requirement to roll a release? (steps 12, 13, 14)
> Under present procedures, rolling a release takes special private
> management procedures, and a second round of review/test/vote (after the
> patch had already been reviewed and tested), as well as the usual
> "paperwork" associated with a release.
> Even the commit requires a little extra thought to come up with a commit
> message that obfuscates the security relevance of the fix.
> Instead we could release just the patch, initially. Then incorporate it
> into a release later, in the public phase, with less extra work. Daniel and
> I have some more specific ideas on how we could do that.

I believe this approach would make things harder for downstream consumers.
They would need to track new Subversion releases as well as patches, so we
would be shifting more work onto them. This would be unfair on our part,
even given our current predicaments. We should not be offloading our own
release engineering work onto other projects.

Downstream processes are optimized towards the general case across the
software ecosystem, which is updating to a new release which contains
a bunch of fixes.
So I would prefer a new release, together with an updated CHANGES file
which documents the problems we fixed. Even if it's a few weeks late.
That way, downstreams won't have to adjust their existing process.

Also, users would have a much harder time trying to verify what they
are actually running.
Received on 2019-08-28 14:07:48 CEST

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