Geronimo 2.0 Release suspended due to security issue found before release

[Vamsavardhana Reddy-2]

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 <david_jencks@...> 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.
>>
>

[prasad]

Good catch Donald. Can you please throw in a small test(s) in our
testsuite framework so that we can catch things like this ? There are
a lot of tests there already that can act as a template/example and
help you with your testcase.

Let me know if you need more help.

Cheers
Prasad

On 8/13/07, Donald Woods <dwoods@...> wrote:

>
>
> 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.
>
> GERONIMO-3404 was opened for this.
>
> >
> > 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.
>
> +1 on option #2.
>
>
> >
> > 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.
> >
> >
>
>

[Donald Woods]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Where were you thinking?  Should we start a new subdirectory for cmdline
tests?  Or could it go under deployment-testsuite?

-Donald

Prasad Kashyap wrote:

> Good catch Donald. Can you please throw in a small test(s) in our
> testsuite framework so that we can catch things like this ? There are
> a lot of tests there already that can act as a template/example and
> help you with your testcase.
>
> Let me know if you need more help.
>
> Cheers
> Prasad
>
> On 8/13/07, Donald Woods <dwoods@...> wrote:
>>
>> 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.
>> GERONIMO-3404 was opened for this.
>>
>>> 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.
>> +1 on option #2.
>>
>>
>>> 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.
>>>
>>>
>>
>
>

[prasad]

At this point, I am not really sure. We can always easily move them around.

If you have or can envision a lot of CLI tests, we can create a
separate testsuite for it. This separate testsuite won't have to
start/stop selenium server too since it is cmdline.

If you want to drop it under deployment-testsuite for now, that's fine too.

Cheers
Prasad

On 8/14/07, Donald Woods <drw_web@...> wrote:

>
> Where were you thinking?  Should we start a new subdirectory for cmdline
> tests?  Or could it go under deployment-testsuite?
>
> -Donald
>
>
> Prasad Kashyap wrote:
> > Good catch Donald. Can you please throw in a small test(s) in our
> > testsuite framework so that we can catch things like this ? There are
> > a lot of tests there already that can act as a template/example and
> > help you with your testcase.
> >
> > Let me know if you need more help.
> >
> > Cheers
> > Prasad
> >
> > On 8/13/07, Donald Woods <dwoods@...> wrote:
> >>
> >> 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.
> >> GERONIMO-3404 was opened for this.
> >>
> >>> 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.
> >> +1 on option #2.
> >>
> >>
> >>> 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.
> >>>
> >>>
> >>
> >
> >
>
>