Re: proposed plan for moving GNU Crypto to Classpath

Casey Marshall <csm@xxxxxxx> · Tue, 27 Dec 2005 19:25:13 -0800

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.

_______________________________________________
gnu-crypto-discuss mailing list
gnu-crypto-discuss@xxxxxxx
http://lists.gnu.org/mailman/listinfo/gnu-crypto-discuss