Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie

[Raif S. Naffah]

On Thursday 08 December 2005 08:21, Casey Marshall wrote:
> On Dec 6, 2005, at 11:57 PM, Raif S. Naffah wrote:
> > On Wednesday 07 December 2005 04:49, Casey Marshall wrote:
> >> On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote:
> >>> On Tuesday 06 December 2005 18:42, Casey Marshall wrote:
> >>>> A few of us have been throwing around the idea of merging GNU
> >>>> Crypto and Jessie into GNU Classpath, so Classpath will have
> >>>> full support for crypto and SSL "out of the box." We've proposed
> >>>> this before, and I think this idea was mostly approved by the
> >>>> group, but no-one ever got around to doing it.
> >>>>
> >>>> I'd like to propose again that we do this. I'll try to get to
> >>>> this myself, but if I can't get this done, we'll at least have a
> >>>> plan of action. I propose that we
> >>>>
> >>>>    - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto'
> >>>> in GNU Crypto, and merge the current CVS sources into Classpath
> >>>> (not under external/). We then put GNU Crypto into a kind of
> >>>> "stasis" mode, and continue to develop these sources in
> >>>> Classpath. - Rename the root package 'org.metastatic.jessie' to
> >>>> 'gnu.javax.net.ssl' in Jessie, and merge the current sources.
> >>>> Then, I'll stop developing that branch on its own.
> >>>
> >>> does this mean that Classpath's crypto classes will be using the
> >>> GNU Crypto "assembly, cipher, hash, key, mac, mode, pad, prng and
                  ^^^^^^^^
> >>> "sig" sub-packages with the "jce" wrappers?
> >>
> >> Basically yes. The goal is to merge "everything with a JCE
> >> wrapper," because that will fill in many algorithms present in
> >> proprietary VMs, but currently missing in Classpath.
> >
> > cool.  i can help with this task  --can spend ~2hrs/day on this
> > until it's done.
>
> Great! School's out for me right now, so I have my weekends back :-)
>
> >> Things without JCE wrappers don't really make sense for Classpath,
> >> because they aren't portably accessible.
> >
> > dont know exactly what you mean by this but i'll have a closer look
> > at the Classpath classes; it may become evident then.
>
> By this I mean that if something can't be used through J2SE classes,
> then it probably shouldn't be merged, because otherwise we'd be
> introducing private, non-portable APIs into Classpath. Exceptions are
> things we know we'll need to use privately (e.g., if Jessie needs
> it).
>
> The assembly package is a good example: it's a neat, advanced API,
> but doesn't have any analogue in the J2SE spec.

ahhh... i was afraid of that, that's why i asked about it earlier and i 
was led to believe it will be part of Classpath.

i still haven't had the time to study closely the security classes in 
Classpath, but consider the following:

* the GNU Provider can implement the triplet cipher/mode/pad using the 
Assembly classes.

* the gnu.* subpackages that provide the implementation for the GNU 
Provider, if/when Classpath's single jar is broken into multiple jars, 
can then be (jarred as one of Classpath's jars, and) used by others 
wishing to use an API other than the JCA.

how does that sound?


> Thanks.


cheers;
rsn

pgpPeiFJ6Upxh.pgp
Description: PGP signature