[Top][All Lists]

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

Re: proposed plan for moving GNU Crypto to Classpath

From: Casey Marshall
Subject: Re: proposed plan for moving GNU Crypto to Classpath
Date: 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

  - 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 "[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 ( 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

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

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

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

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, 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 < jessie.patch> and a tarball of new files at < source/gnu-crypto-jesise.tar.gz>.


reply via email to

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