Re: Security patches release process

2013-08-08 Thread Ben Reser
On Thu, Aug 8, 2013 at 3:13 AM, Stefan Sperling wrote: > The assertion that packagers only use unmodified tarball is strange to > me. Packagers routinely patch upstream software to make it work on their > system or to backport security fixes. But usually the version number of > the upstream releas

Re: Security patches release process

2013-08-08 Thread Stefan Sperling
On Thu, Aug 08, 2013 at 12:51:06PM +0300, Daniel Shahaf wrote: > Ben Reser wrote on Thu, Aug 08, 2013 at 00:58:50 -0700: > > On Wed, Aug 7, 2013 at 3:49 AM, Justin Erenkrantz > > wrote: > > > I'm okay with choice 3 - however, the "release a signed .diff" should also > > > include a full release -

Re: Security patches release process

2013-08-08 Thread Daniel Shahaf
Daniel Shahaf wrote on Thu, Aug 08, 2013 at 12:51:06 +0300: > (a) - Unidiffs in /repos/private/pmc/subversion > (b) - Branch in /repos/asf/subversion/shadow > (c) - Branch in /repos/private/pmc/subversion/shadow > (d) - Branch in fossil/bzr/hg/git > (e) - (We could ask infra to 'zfs clone' the asf

Re: Security patches release process

2013-08-08 Thread Daniel Shahaf
Ben Reser wrote on Thu, Aug 08, 2013 at 00:58:50 -0700: > On Wed, Aug 7, 2013 at 3:49 AM, Justin Erenkrantz > 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

Re: Security patches release process

2013-08-08 Thread Ben Reser
On Wed, Aug 7, 2013 at 3:49 AM, Justin Erenkrantz 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.

Re: Security patches release process

2013-08-07 Thread Justin Erenkrantz
On Wed, Aug 7, 2013 at 5:48 AM, Daniel Shahaf wrote: > (v3) > - Receive report > - Come up with a fix > - Gather 3 +1 votes via shadow status file > - Send pre-notifications > - Release a signed .diff file (instead of a tarball) as 1.8.(x+1) > - Commit fix with a log message clearly outlining the

Security patches release process

2013-08-07 Thread Daniel Shahaf
(See https://www.apache.org/security/committers for background) For CVE-2013-4131 our process was: (v1) - Receive report - Come up with a fix - Gather 3 +1 votes via shadow status file - Commit fix with innocent log message - Backport without going via STATUS - Tag and roll 1.8.(x+1) - In paralle