You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2007/08/13 22:59:05 UTC
Geronimo 2.0 Release suspended due to security issue found before release
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.
Re: Geronimo 2.0 Release suspended due to security issue found before
release
Posted by Hernan Cunico <hc...@gmail.com>.
Here is the link to the dev site home page with the latest update
http://cwiki.apache.org/GMOxSITE/
within the next hour geronimo.apache.org should get updated.
Cheers!
Hernan
Hernan Cunico wrote:
> +1 for option 2, it seems the quickest one.
>
> I just put the "News" out, it takes some time to get propagated.
>
> Cheers!
> Hernan
>
> 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.
>>
>
Re: Geronimo 2.0 Release suspended due to security issue found before
release
Posted by Hernan Cunico <hc...@gmail.com>.
+1 for option 2, it seems the quickest one.
I just put the "News" out, it takes some time to get propagated.
Cheers!
Hernan
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.
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 13, 2007, at 4:59 PM, Matt Hogstrom wrote:
> 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.
Agreed.
--kevan
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Paul McMahan <pa...@gmail.com>.
On Aug 13, 2007, at 4:59 PM, Matt Hogstrom wrote:
> 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.
+1 for option 2
Best wishes,
Paul
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Prasad Kashyap <go...@gmail.com>.
+1 to option 2.
Let's get 2.0.1 out of the door ASAP.
Cheers
Prasad
On 8/13/07, Matt Hogstrom <ma...@hogstrom.org> 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.
>
Re: Geronimo 2.0 Release suspended due to security issue found before
release
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
+1 for option 2
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Jarek Gawor <jg...@gmail.com>.
+1 for option 2.
Jarek
On 8/13/07, Matt Hogstrom <ma...@hogstrom.org> 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.
>
Re: Geronimo 2.0 Release suspended due to security issue found before
release
Posted by Joe Bohn <jo...@earthlink.net>.
+1 to option 2
Joe
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.
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Prasad Kashyap <go...@gmail.com>.
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 <dw...@apache.org> 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.
> >
> >
>
>
Re: Geronimo 2.0 Release suspended due to security issue found before
release
Posted by Donald Woods <dw...@apache.org>.
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.
>
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Jarek Gawor <jg...@gmail.com>.
Matt,
We could at least release/publish the transaction and connector bits, right?
Jarek
On 8/13/07, Matt Hogstrom <ma...@hogstrom.org> 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.
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
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 <da...@yahoo.com> 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.
> >>
> >
>
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by David Jencks <da...@yahoo.com>.
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.
>>
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 13, 2007, at 9: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'm looking things over now... May take me a bit... Easy to get this
logic a bit twisted...
>
> 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.
Hmm. I was thinking the big issue was with the SUFFICIENT flag -- if
a SUFFICIENT LoginModule succeeds, authentication does not proceed
down the chain of LoginModules. Thus the
SubjectLoginRegistrationModule might not be invoked.
Likewise, if a REQUISITE LoginModule fails, the
SubjectLoginRegistrationModule wouldn't be invoked. Since the login
won't succeed, this doesn't seem like a big issue. Am I missing
something?
>
> 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?
I'm not having a problem...
--kevan
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On 8/14/07, David Jencks <da...@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.
> >
>
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by David Jencks <da...@yahoo.com>.
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.
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
David,
Though there are a few other minor fixes (that may not come in the way of
TCK, for e.g. R565355) that I would have wanted in 2.0.1, I felt that this
may not be the right time to bring up those as we may not "any" additional
delays in getting 2.0.1 out, perhaps we may have to think about a 2.0.2 out
of the current branches\2.0 and save these for then. As always, it is RMs
call.
Vamsi
On 8/14/07, David Jencks <da...@yahoo.com> 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.
>
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I'll go ahead and update branches/2.0 to 2.0.2-SNAPSHOT as this needs
to be done regardless.
On Aug 13, 2007, at 8: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.
>
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by David Jencks <da...@yahoo.com>.
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.
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
At this point, we will want to get a release out fast and address only those
issues (like the security bug Donald has found and hopefully only this) that
are blocker.
+1 to option 2, create branches\2.0.1 from tags\2.0.0.
Vamsi
On 8/14/07, Matt Hogstrom <ma...@hogstrom.org> 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.
>
Re: Geronimo 2.0 Release suspended due to security issue found before release
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
+1 to option #2
Cheers!
Anita
--- Matt Hogstrom <ma...@hogstrom.org> 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.
>
____________________________________________________________________________________
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz