Verified that the fixes address the security bug Donald has identified. No
regression is observed in case of GERONIMO-2266 and GERONIMO-2267. I
suggest others verify any scenarios they can think of for possible
regression.
Vamsi
On 8/14/07, David Jencks <[EMAIL PROTECTED]> wrote:
>
> I've now fixed GERONIMO-3407 in trunk, rev 565657. I added new
> methods to ContextManager and removed direct use of LoginContext.
> Among other things this may make implementing jaspi slightly easier.
>
> New methods are:
> public static LoginContext login(String realm, CallbackHandler
> callbackHandler) throws LoginException {
> Subject subject = new Subject();
> LoginContext loginContext = new LoginContext(realm, subject,
> callbackHandler);
> loginContext.login();
> SubjectId id = ContextManager.registerSubject(subject);
> IdentificationPrincipal principal = new
> IdentificationPrincipal(id);
> subject.getPrincipals().add(principal);
> return loginContext;
> }
>
> public static void logout(LoginContext loginContext) throws
> LoginException {
> Subject subject = loginContext.getSubject();
> ContextManager.unregisterSubject(subject);
> loginContext.logout();
> }
>
>
> This revision needs to be ported to branches/2.0 and wherever 2.0.1 is.
>
> thanks
> david jencks
>
> On Aug 13, 2007, at 6:27 PM, David Jencks 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.
> >
> > 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.
> >>
> >
>
>
