Geronimo 2.0 Release suspended due to security issue found before release

[Matt Hogstrom]

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.

[Vamsavardhana Reddy-2]

At this point, we will want to get a release out fast and address only those issues (like the security bug Donald has found and hopefully only this) that are blocker.

+1 to option 2, create branches\2.0.1 from tags\2.0.0.

Vamsi

On 8/14/07, Matt Hogstrom <matt@...> 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.

[Jarek Gawor-2]

+1 for option 2.

Jarek

On 8/13/07, Matt Hogstrom <matt@...> 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.
>

[Jay D. McHugh]

+1 for option 2

[Donald Woods-2]

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.
>
>

[Paul McMahan]

On Aug 13, 2007, at 4:59 PM, Matt Hogstrom wrote:

> 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.

+1 for option 2


Best wishes,
Paul

[Hernan Cunico]

+1 for option 2, it seems the quickest one.

I just put the "News" out, it takes some time to get propagated.

Cheers!
Hernan

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.
>

[Hernan Cunico]

Here is the link to the dev site home page with the latest update

http://cwiki.apache.org/GMOxSITE/

within the next hour geronimo.apache.org should get updated.

Cheers!
Hernan

Hernan Cunico wrote:

> +1 for option 2, it seems the quickest one.
>
> I just put the "News" out, it takes some time to get propagated.
>
> Cheers!
> Hernan
>
> 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.
>>
>

[Joe Bohn]

+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.
>

[Kevan Miller]

On Aug 13, 2007, at 4:59 PM, Matt Hogstrom wrote:

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.

Agreed.

--kevan

[anita kulshreshtha]

+1 to option #2

Cheers!
Anita

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

[djencks]

So before we all jump onto option 2 maybe we should consider just how  
big a change this set of bugs is causing and comparatively how much  
branches/2.0 has changed since 2.0.0 was cut.

It looks like there have been about 15 commits to branches/2.0 that  
aren't version changes, many of them simple fixes that make things  
like the plugin installer actually usable.  On the other hand so far  
I've modified 16 files working on this security fix (admittedly most  
of them either simple fixes and/or documentation) and still have to  
figure out a solution to SubjectRegistrationLoginModule not working  
(GERONIMO-3407)

If we go with  (2) I would like some of the changes to branches/2.0  
to be merged in, especially rev 563592.  I think r563662 and r563782  
would be good also.

thanks
david jencks

On Aug 13, 2007, at 1:59 PM, 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.

[Jarek Gawor-2]

Matt,

We could at least release/publish the transaction and connector bits, right?

Jarek

On 8/13/07, Matt Hogstrom <matt@...> 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.
>

[djencks]

I think I've fixed GERONIMO-3404 and GERONIMO-3406 in trunk, rev  
565599.  It might be a good idea for this to get a review before we  
port it to branches/2.0 and possibly branches/2.0.x.

I haven't decided how to fix GERONIMO-3407 yet, and could be talked  
out of it for 2.0.1. The problem would manifest itself as geronimo  
not working if anyone tried to  use a login module with REQUISITE or  
(I think) SUFFICIENT flags.  I don't think there's any security  
exposure, it just that you effectively couldn't log in with such a  
login configuration.

On a completely unrelated issue I can't build modules/geronimo-axis-
builder in trunk as part of the main build, I get a complaint from  
javac.  I don't have problems building it by itself.  Anyone else see  
this?

thanks
david jencks
On Aug 13, 2007, at 5:03 PM, David Jencks wrote:

> So before we all jump onto option 2 maybe we should consider just  
> how big a change this set of bugs is causing and comparatively how  
> much branches/2.0 has changed since 2.0.0 was cut.
>
> It looks like there have been about 15 commits to branches/2.0 that  
> aren't version changes, many of them simple fixes that make things  
> like the plugin installer actually usable.  On the other hand so  
> far I've modified 16 files working on this security fix (admittedly  
> most of them either simple fixes and/or documentation) and still  
> have to figure out a solution to SubjectRegistrationLoginModule not  
> working (GERONIMO-3407)
>
> If we go with  (2) I would like some of the changes to branches/2.0  
> to be merged in, especially rev 563592.  I think r563662 and  
> r563782 would be good also.
>
> thanks
> david jencks
>
> On Aug 13, 2007, at 1:59 PM, 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.
>

[prasad]

+1 to option 2.

Let's get 2.0.1 out of the door ASAP.

Cheers
Prasad

On 8/13/07, Matt Hogstrom <matt@...> 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.
>

[Matt Hogstrom]

I'll go ahead and update branches/2.0 to 2.0.2-SNAPSHOT as this needs  
to be done regardless.


On Aug 13, 2007, at 8:03 PM, David Jencks wrote:

> So before we all jump onto option 2 maybe we should consider just  
> how big a change this set of bugs is causing and comparatively how  
> much branches/2.0 has changed since 2.0.0 was cut.
>
> It looks like there have been about 15 commits to branches/2.0 that  
> aren't version changes, many of them simple fixes that make things  
> like the plugin installer actually usable.  On the other hand so  
> far I've modified 16 files working on this security fix (admittedly  
> most of them either simple fixes and/or documentation) and still  
> have to figure out a solution to SubjectRegistrationLoginModule not  
> working (GERONIMO-3407)
>
> If we go with  (2) I would like some of the changes to branches/2.0  
> to be merged in, especially rev 563592.  I think r563662 and  
> r563782 would be good also.
>
> thanks
> david jencks
>
> On Aug 13, 2007, at 1:59 PM, 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.
>
>