Re: proposed plan for moving GNU Crypto to Classpath

[Casey Marshall]

On Dec 27, 2005, at 8:49 AM, Raif S. Naffah wrote:

> hello all,
>
> here is a proposed plan for the move:
>
> * create a gnu.classpath.crypto package hierarchy which will  
> contain the
> following (GNU Crypto) sub-packages:
>
>   - auth
>   - hash
>   - jce --renamed java
>   - key
>   - keyring
>   - pki

Don't merge the pki package; Classpath has a version of this (the GNU  
Crypto version was prototypical) in gnu.java.security.x509.

>   - prng --weak algos
>   - sasl
>   - sig
>   - util
>
> * create a new source folder named 'crypto' which will contain another
> gnu.classpath.crypto package hierarchy consisting of the following  
> (GNU
> Crypto) sub-packages:
>
>   - assembly
>   - cipher
>   - (outer) jce --renamed javax
>   - mac
>   - mode
>   - pad
>   - prng --strong algos

I don't like 'gnu.classpath.crypto.' The normal convention in  
Classpath has been to prefix "mere implementation classes" with  
"gnu.java[x]." The "gnu.classpath" packages are usually completely  
private to Classpath.

> * the basic criterion for the division into the above trees is that  
> the
> first one will contain the weak (non-export-controlled) ones, while  
> the
> second will contain the strong (export-controlled) ones.  packages
> containing mixed strong and weak crypto will have their contents
> divided between the two and their Factory class re-written as a
> template (xxxFactory.java.in) which will be conditioned by a
> configuration parameter, say 'enable-strong-crypto' (set to true by
> default).
>   another alternative would be to supply two different implementations
> of the Factory class; the one in the strong branch, providing all the
> implementations, relies on the make process to have the strong version
> over-write the weak one when enable-strong-crypto is true (default
> behaviour).

I'd prefer to keep ".in" files to a minimum. We could attain the same  
thing by using reflection for the parts that may or may not be  
available or are disabled at compile time.

> * the 'make' process should be amended to merge (or include), or not,
> depending on the value of the enable-strong-crypto configuration
> option, the two sub-trees before building glibj.  it should also cater
> for the second JCE Security Provider when generating the
> classpath.security properties file.
>
> * when classes from GNU Crypto, rely on AWT or Swing, they will be
> re-written as templates conditioned by existing Classpath  
> configuration
> option(s).

Why is that needed? Aren't AWT and Swing still available, even if no  
native peers are compiled?

> * amend the current JCE Security Provider --Gnu in the package
> gnu.java.security.provider-- to provide the additional weak crypto
> stuff.
>
> * remove duplicate or similar classes from gnu.java.security.provider
> which are now implemented in gnu.classpath.crypto.
>
> * create a new JCE Security Provider, GnuCrypto, under the crypto  
> source
> folder in gnu.classpath.crypto.javax package that provides the
> additional strong stuff.
>
> * create a new source folder named 'junit' which will contain the  
> JUnit
> test cases ported from GNU Crypto mauve-like testlets.

Are there any opinions about adding test suites to Classpath? It  
seems to me like that had been abandoned in favor of an external test  
suite (Mauve).

> practically, all this would be done consecutively in two major  
> series of
> commits: the non-export-controlled stuff, and later the
> export-controlled stuff (i.e. the crypto top-level source folder).
>
>
> comments, suggestions?

I had put together my own proposed patch set, and sent a message  
about it from an address that needs approval for classpath-patches  
(I'm writing this over a slow VNC connection). It's rather simpler  
than this, and mostly just involves renaming gnu.crypto to  
gnu.javax.crypto, and org.metastatic.jessie to gnu.javax.net.ssl, and  
adds a configure switch to disable compiling crypto classes (I'd  
rather avoid doing a lot to support export control, because AFAIK  
only one person needs it (sorry, Anthony ;-) and it is more  
infrastructure to maintain). It may make sense to "bifurcate" GNU  
Crypto into "weak" and "strong" eventually, however.

The patch is at <http://metastatic.org/source/gnu-crypto- 
jessie.patch> and a tarball of new files at <http://metastatic.org/ 
source/gnu-crypto-jesise.tar.gz>.

Thanks.