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

[Raif S. Naffah]

On Saturday 07 January 2006 05:48, Casey Marshall wrote:
> 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.

no. that does not make sense; unless... we do something like this:

abstract class WeakOrStrongXxxFactory implements IFactory {
  ...
}

public abstract XxxFactory implements IFactory {
   private static IFactory weakFactory;
   private static IFactory strongFactory;
   static {
      weakFactory = new WeakXxxFactory();
      strongFactory = Configuration.ENABLE_STRONG_CRYPTO
            ? new StrongXxxFactory()
            : null;
   }

   pubic static final IXxx getInstance(String name) {
      Ixxx result = weakFactory.getInstance(name);
      if (result != null)
         return result;

      if (strongFactory != null)
         return strongFactory.getInstance(name);
   }
...
}

interface IXxxFactory {
   getInstance...
   getNames...
}
  

> 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?).

Key pairs: DSS (weak) - DH and RSA (strong)
Signatures: DSS (weak) - RSA (strong)


> 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.

i don't think it's a good idea to drop the Factory Pattern, just because 
it is more convenient for packaging.  we can debate that issue on the 
GNU Crypto list if you want.


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

-- 
cheers;
rsn

pgpESrelbO1W5.pgp
Description: PGP signature