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