Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=GLdvUmlJBqMZuaTP7tBgweR8zSB60RyhZxCsBYC5u+Axe5JS7C6pkXI/Luen5/IQ;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <46C0CF1F.50908@earthlink.net>
Date: Mon, 13 Aug 2007 17:37:35 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Geronimo 2.0 Release suspended due to security issue found before
 release
References: <BB2309A9-BEDA-49BE-922D-C7B3E070C2C7@hogstrom.org>
In-Reply-To: <BB2309A9-BEDA-49BE-922D-C7B3E070C2C7@hogstrom.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1 to option 2

Joe

Matt Hogstrom wrote:
> All,
> 
> Earlier today one of the Geronimo committers discovered a bug in the 
> command line deployer where a null user / password on the deployer 
> command line will allow a user to deploy modules to a 2.0 server.  This 
> is an unacceptable security exposure and as such we have abandoned the 
> release of Geronimo 2.0.
> 
> Donald Woods is going to open a JIRA for this issue and Hernan will 
> create a news item on our web page.
> 
> At this point we need to discuss how to move forward with a 2.0 release.
> 
> I think we should delete the tags/2.0.0 entry and replace it with a text 
> file that notes the svn rev of the tree before deletion.  The purpose of 
> this is to avoid anyone from picking up that source tree and using it to 
> build a server with a known security exposure.  Unless there is 
> disagreement I'd like to do that tomorrow allowing some time for 
> discussion.  We can always put it back.
> 
> There are several options for the 2.0 release:
> 
> 1. Use the branches/2.0 to spin up a new release as 2.0.1.
>   If we do this there are a number of fixes that need to be verified, 
> We'd need to close out the SNAPSHOT releases again, or at least revisit 
> them.
>   Respin and re-tck a new release.
> 
> 2. Take the tags/2.0.0 to create a branches/2.0.1
>   This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT
>   Copy the existing tag over and apply the security fixes.  Repsin and 
> release.
> 
> Personally, I vote for option 2.  Based on my experience, closing out 
> the SNAPSHOTs is and introducing little changes will cause us to restart 
> the release process.
> 
> I'd like to hear other people's input but having done the release 
> several times option 2 is the fastest.  I think option 1 will cause us 
> to not release until September.
>