[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proposed plan for moving GNU Crypto to Classpath

From: Raif S. Naffah
Subject: proposed plan for moving GNU Crypto to Classpath
Date: Wed, 28 Dec 2005 03:49:55 +1100
User-agent: KMail/1.9.1

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 ( which will be conditioned by a 
configuration parameter, say 'enable-strong-crypto' (set to true by 
  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 

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

* when classes from GNU Crypto, rely on AWT or Swing, they will be 
re-written as templates conditioned by existing Classpath configuration 

* amend the current JCE Security Provider --Gnu in the package to provide the additional weak crypto 

* remove duplicate or similar classes from 
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?


Attachment: pgpO5f8UzcSJU.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]