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.
