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

Re: Security patches release process

From: Ben Reser <ben_at_reser.org>
Date: Thu, 8 Aug 2013 00:58:50 -0700

On Wed, Aug 7, 2013 at 3:49 AM, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:
> I'm okay with choice 3 - however, the "release a signed .diff" should also
> include a full release - including whatever normal things we include with a
> standard release process. If 1.8.(x+1) is *only* available as a diff
> against 1.8.x, that makes it hard for downstream users (or packagers) until
> 1.8.(x+2) is released. -- justin

Not having tarballs is a huge problem since our most reliable
packagers just release the latest version and don't put out patches.

To this end I suggest a fourth alternative.

(v4)
- Receive report
- Come up with a fix
- Have a private section of our tree that is always hidden and doesn't
announce commits on public lists/svnpubsub. Create branches there to
commit the work and handle the release branch from there.
- Backport to the hidden branches and use the STATUS files there to vote.
- Tag and roll 1.8.(x+1) off the hidden branch (our CHANGES file
already says which branch we cut a release from simply set it where
the branch will be after moving it out of the private area), tag also
goes to the hidden branch area.
- Place dist files on password protected website for votes and
pre-notifications.
- In parallel:
  + Gather release votes
  + Send pre-notifications
- In parallel:
  + Merge back to publicly visible branches/move the private branches
into the public areas.
  + Release + announce publicly.

We can even continue to vote on un-related issues in the normal
locations and simply merge them across. The only diff between the
private branch and the public branch would be the security fixes.

It probably will take some adjustment to some of the tools to support
this I don't think svnpubsub and the emailer can ignore subtrees and
we might want to make backport.pl capable of handling some of the
merging for us. But none of this seems particularly difficult to me.

The only hole left is we need to place tarballs on the dist site 24
hours in advance to mirror. However, I think we can simply workaround
this issue for serious security issues by shortening that window and
using the update flag on the download page.
Received on 2013-08-08 09:59:29 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.