geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <drw_...@yahoo.com>
Subject Re: Geronimo 2.0 Release suspended due to security issue found before release
Date Tue, 14 Aug 2007 16:42:27 GMT
Where were you thinking?  Should we start a new subdirectory for cmdline 
tests?  Or could it go under deployment-testsuite?

-Donald

Prasad Kashyap wrote:
> Good catch Donald. Can you please throw in a small test(s) in our
> testsuite framework so that we can catch things like this ? There are
> a lot of tests there already that can act as a template/example and
> help you with your testcase.
> 
> Let me know if you need more help.
> 
> Cheers
> Prasad
> 
> On 8/13/07, Donald Woods <dwoods@apache.org> wrote:
>>
>> 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.
>> GERONIMO-3404 was opened for this.
>>
>>> 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.
>> +1 on option #2.
>>
>>
>>> 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.
>>>
>>>
>>
> 
> 



Mime
View raw message