geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <c1vams...@gmail.com>
Subject Re: Geronimo 2.0 Release suspended due to security issue found before release
Date Tue, 14 Aug 2007 05:09:23 GMT
On 8/14/07, David Jencks <david_jencks@yahoo.com> 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.
> >
>
>

Mime
View raw message