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 <[EMAIL PROTECTED]> 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. > > > > > >
