David, Though there are a few other minor fixes (that may not come in the way of TCK, for e.g. R565355) that I would have wanted in 2.0.1, I felt that this may not be the right time to bring up those as we may not "any" additional delays in getting 2.0.1 out, perhaps we may have to think about a 2.0.2 out of the current branches\2.0 and save these for then. As always, it is RMs call.
Vamsi On 8/14/07, David Jencks <[EMAIL PROTECTED]> 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. > >
