Re: Geronimo 2.0 Release suspended due to security issue found before release
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 <[EMAIL PROTECTED]> 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
+1 for option 2. Jarek On 8/13/07, Matt Hogstrom <[EMAIL PROTECTED]> 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
+1 for option 2
Re: Geronimo 2.0 Release suspended due to security issue found before release
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: Geronimo 2.0 Release suspended due to security issue found before release
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
+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
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
+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
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
+1 to option #2 Cheers! Anita --- Matt Hogstrom <[EMAIL PROTECTED]> 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
Re: Geronimo 2.0 Release suspended due to security issue found before release
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
Matt, We could at least release/publish the transaction and connector bits, right? Jarek On 8/13/07, Matt Hogstrom <[EMAIL PROTECTED]> 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
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
+1 to option 2. Let's get 2.0.1 out of the door ASAP. Cheers Prasad On 8/13/07, Matt Hogstrom <[EMAIL PROTECTED]> 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
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
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
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 <[EMAIL PROTECTED]> 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
On 8/14/07, David Jencks <[EMAIL PROTECTED]> 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
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
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 cau
Re: Geronimo 2.0 Release suspended due to security issue found before release
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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. > >>> > >>> > >> > > > > > >
