geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo 2.0 Release suspended due to security issue found before release
Date Tue, 14 Aug 2007 01:27:30 GMT
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.
>


Mime
View raw message