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

[Casey Marshall]

On Jan 6, 2006, at 12:41 AM, Raif S. Naffah wrote:

> On Friday 06 January 2006 10:07, Casey Marshall wrote:
> > After thinking about exportability a little more, I think the best
> > option may be to not provide any `--disable-crypto' option at all,
> > and just structure the source code so that packagers can remove all
> > non-exportable crypto by just removing whole directories. The build
> > system doesn't care if you remove an entire package, anyway.
> >
> > This is a little closer to what Raif suggested, but I'd suggest not
> > doing it by splitting the hierarchy up. That is, instead of making
> > the boundary:
> >
> >    <root>/gnu/javax/crypto/prng             <-- weak algs
> >    <root>/non-export/gnu/javax/crypto/prng  <-- strong algs
> >
> > We just shove exportable algorithms and providers under `gnu/java/
> > security,' and non-exportable algorithms and providers under `gnu/
> > javax/crypto.' Thus, if you need to make an exportable source/binary,
> > just `rm -rf {,gnu/}javax/crypto.' It's more of a manual process, but
> > very easy.
> >
> > How does this sound?
>
> how do you address the Factory classes? a Factory for a split  
> "service"
> must see all its subordinates, which are different depending on  
> whether
> the non-exportable stuff is in or out.  yes?

Splitting into strong and weak factories might be the best bet.  
Otherwise, I'd instead try using reflection for the strong  
algorithms, which may not exist at runtime. There will be a split  
between JCE providers on strong/weak boundaries anyway.

This seems kind of academic, though, because I don't think there are  
many packages that need to be split in half based on strength (PRNG,  
obviously. Anything else?). Also, we don't really need the Factory  
classes in most places, like the JCE adapters, because we can just  
replace calls to

  FooFactory.getInstance ("Bar");

to

  new Bar ();

As a stand-alone API, the factory classes should have used reflection  
and had some amount of configurability, because as-is they aren't all  
that flexible.

And, these classes are all internal, so it doesn't have to make any  
sense beyond what we need to implement our security providers.