proposed plan for moving GNU Crypto to Classpath

[Raif S. Naffah]

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

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

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

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


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?


cheers;
rsn

pgpO5f8UzcSJU.pgp
Description: PGP signature