Re: [cp-patches] GNU Crypto and Jessie merge

[Casey Marshall]

On Jan 5, 2006, at 12:21 PM, Raif S. Naffah wrote:

> hello Mark and Casey,
>
> (i'm cc-ing Tom on this)
>
> On Friday 06 January 2006 06:45, Casey Marshall wrote:
> > On Jan 5, 2006, at 3:58 AM, Mark Wielaard wrote:
> > > On Sun, 2005-12-25 at 17:06 -0800, Casey Marshall wrote:

[...]

> > > > I know some have expressed
> > > > concern over including crypto in Classpath, and wanted to know if
> > > > the configure switch will suffice for them.
> > >
> > > I am not sure the --disable-crypto part is enough to disable all
> > > crypto[-hooks] so I would only include this if Anthony confirms
> > > this is
> > > really what is needed to make the resulting binary "exportable" for
> > > him.
> > > If not then I think we should not include it because people might
> > > rely on that switch to purge all crypto things. (We already have
> > > crypto in GNU Classpath since the 0.11 release, this only adds more
> > > and stronger algorithms.)
> >
> > We could extend the --disable-crypto option to disable the
> > javax.crypto and javax.net.ssl hooks, as well, if that will meet the
> > needs for exportable classpath. It's easy to do that by adding
> > patterns to the omit file.
> >
> > And, the --disable-crypto option should be refined, because now it
> > eliminates everything from GNU Crypto, even the stuff that is
> > exportable. We can do this after the merge, though: it will be easier
> > (I think) to push the classes into the tree, as close to as they
> > exist now, and then refine things.
>
> indeed.  my proposed plan was (a) to get in the tree as much GNU  
> Crypto
> code as possible, and (b) to address Anthony's concern about the
> exportability of the code --i look forward to see his reply re. how he
> is dealing with the existing crypto-related stuff in the current
> Classpath's HEAD.
>
> this patch does (a) and allows, in time, to address (b).

Something I'm not entirely sure about is whether we want only the  
ability to produce binaries without strong crypto, or source packages  
as well. I'm assuming it's the former, since the latter is impossible  
to meaningfully enforce.

And, a lot more people want (a) than want (b).

> some more refinements, which can be done subsequent to the merge --and
> which i can work on if there are no objection (i'd hate to do the  
> work,
> submit a patch and then get a negative response)-- follow:
>
> * combine the GNU and the GNU_SECURITY providers into one, and  
> leave the
> other providers.

Yes, this should be done. I don't think it makes much sense to split  
the gnu.javax.crypto package into two packages based on export/non- 
export lines, though; it would make disabling strong crypto easier  
(disable the strong package), but is a lot more moving/renaming  
things -- which I don't mind, but find it's a tedious thing to do,  
and I don't have that much time to devote to it.

> * ensure that internally, to Classpath, all crypto-related classes use
> the gnu.javax.crypto classes.

This should be done, too. I think GCJ internal classes use  
gnu.java.security.provider classes directly.

> > ...
> > This will probably happen after 0.20.
>
> if you haven't done so already, i can work on the Mauve part.

Yes, please go ahead.

Thanks.