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=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=z1nr9ow+PlXcXsPhuU/I0AY3Iv843CNGxI2m4jASILdyVR8Y7k0GTWNTLZec2IlbeFYF+T7bP0oKPdoenmV843lKGxY/FAM4F+skNrxAs3/SQwLFlq+xJiZdgXj8CT8ylC6BjKvVJ92DmbC9CYduvvir5G69cZ2LazhcoJ+842Q=;
Date: Mon, 13 Aug 2007 16:28:09 -0700 (PDT)
From: Anita Kulshreshtha <a_kulshre@yahoo.com>
Subject: Re: Geronimo 2.0 Release suspended due to security issue found before
 release
To: dev@geronimo.apache.org
In-Reply-To: <BB2309A9-BEDA-49BE-922D-C7B3E070C2C7@hogstrom.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <858419.59261.qm@web31705.mail.mud.yahoo.com>

+1 to option #2

Cheers!
Anita

--- Matt Hogstrom <matt@hogstrom.org> 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.
> 


____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz