On 8/14/07, David Jencks <[EMAIL PROTECTED]> wrote: > > 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.
We may also want to make sure GERONIMO-2266, GERONIMO-2267 and any similar ones do not recur. 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. > > > >
