geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: [VOTE]Re: M5 Cut proposal date
Date Fri, 09 Sep 2005 11:55:31 GMT
Geir Magnusson Jr. wrote:

>
> On Sep 9, 2005, at 2:39 AM, David Jencks wrote:
>
>> I think we've made significant progress in the last week towards  
>> being ready to make the branch for M5, but I think there may be  
>> reasons to wait a couple more days.  There are 2 features that  
>> people want to get in (security improvements and DDL generation)  
>> that I would like to see in M5, and more stabilization is needed in  
>> any case before the release.  I think that unless someone is  waiting 
>> to get a new feature in that shouldn't go in M5 we should  wait until 
>> monday and see where we are.
>>
>> If anyone is contemplating a commit that may destabilize our code  
>> please speak up so we can branch beforehand.
>
>
> Along with your list in the initial thread, we need to deal with the  
> BouncyCastle situation, since we need to stop shipping this jar.  The  
> status quo is unacceptable because of the patent encumbrance of IDEA  
> and therefore the liability that could be accidentally triggered.   
> Rick has done some great work on hunting this down. (http:// 
> issues.apache.org/jira/browse/GERONIMO-880) I think the fix is easy  
> on our side - we can just change the keystore portlet to detect BC  
> and do something different if not there (like show a page telling  
> user where to get it if they want it, etc...)  but right now, we need  
> OpenEJB to remove the dependency.  For OpenEJB, I think there are two  
> aspects - the inclusion of IDEA in the SSLCipherSuite list (modules/ 
> core/src/java/org/openejb/corba/sunorb/SSLCipherSuiteDatabase.java)  
> and it's usage of the ASN1 codec.  I don't know what they (OpenEJB)  
> want to do there - it's been suggested that the necessary code can be  
> copied (it's under a modified X.Net-ish license) or Directory could  
> be enhanced and used.  It seems the former is simpler.
>
> Ideas?  (No pun intended...)

I've taken a look at both solutions for the openejb ASN1 usage.  The 
ASN1 bouncy castle code is realatively selfcontained, and can be 
separated out an repackaged relatively quickly.  I've already managed to 
build a version of the BC code that contains just the classes necessary 
to get the asn1 subdirectory to compile, and am working on a "pruned" 
version that removes support not likely to be required for 
openejb/geronimo.  Once that is done, the changes to openejb are pretty 
trivial (mostly just changing package names).  Right now, I'm planning 
on creating a util module in Geronimo for this to live.

The Directory stuff is a little trickier.  The Directory ASN1 support 
doesn't include support for different types of objects that use ASN1 
encodings (in this case X509 names).  I took a crack at writing the 
equivalent, and found the Directory ASN1 support to be incomplete enough 
that you'd end up reimplementing a lot of the bc classes in the 
Directory.  A "quick-and-dirty" approach just implementing X509 name 
parsing in the openejb Util module look doable, but was still a fairly 
tricky bit of code AND required some enhancements to the Directory ans1 
support to implement.  Right now, the bc subset version looks like the 
best route to take.


>
> geir
>
>>
>> thanks
>> david jencks
>>
>> On Sep 6, 2005, at 9:33 PM, Jeff Genender wrote:
>>
>>
>>> Ok ...I am hijacking this thread... enough discussion...lets vote  
>>> on it...
>>>
>>> [ ] Friday 9/9 is the QA Cut date
>>> [ ] I think it should be after Friday...and should be on ______
>>>
>>>
>>> For me:
>>> [X] Friday 9/9 is the QA Cut date
>>>
>>>
>>> David Blevins wrote:
>>>
>>>> On Sep 6, 2005, at 6:50 PM, Jeff Genender wrote:
>>>>
>>>>>
>>>>>
>>>>> Aaron Mulder wrote:
>>>>>
>>>>>
>>>>>>     What is the point of the "frozen list"?  At this point, it  

>>>>>> doesn't appear to have stopped development of things that  
>>>>>> aren't  on the list.
>>>>>>
>>>>>>
>>>>>
>>>>> The list for what we are agreeing to go into M5.  If something   
>>>>> isn't on the list and its an added bonus, then fine.  We need a   
>>>>> closure date at this point.  I think we have all agreed what is   
>>>>> minimally in the cut.
>>>>>
>>>>>
>>>>>
>>>>>>     Maybe we should make the branch like Friday, so any code  not
on
>>>>>> the list has to go into HEAD, and just have a longer closing   
>>>>>> period to
>>>>>> resolve the list items.  There is a lot on the list, so that  
>>>>>> would  mean a
>>>>>> lot of merges to HEAD, but unless everyone is willing to hold  
>>>>>> off on
>>>>>> non-list items, I'm not sure we're actually moving toward  
>>>>>> greater  stability in the mean time.
>>>>>>
>>>>>>
>>>>>
>>>>> Ok..shall we branch on Friday?  Anhyone have any issues with  
>>>>> this?   I am game.
>>>>>
>>>>>
>>>> Friday is great.  Aaron expressed the same concern I was  thinking  
>>>> about; getting further and further from stable the long  we wait 
>>>> to  branch.  Things always tend to creep in.
>>>> +1
>>>> David
>>>>
>>>
>>>
>>
>>
>


Mime
View raw message