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
