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


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

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


_______________________________________________
Classpath mailing list
Classpath@...
http://lists.gnu.org/mailman/listinfo/classpath

[Jeroen Frijters]

Casey Marshall wrote:
> 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.

I agree. At the moment it is possible to compile Classpath without using
any of the build infrastructure, IMO we should aim to keep it that way.

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

Mauve is definitely the place for tests.

Regards,
Jeroen


_______________________________________________
Classpath mailing list
Classpath@...
http://lists.gnu.org/mailman/listinfo/classpath

[Dalibor Topic]

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

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

Yes, please. I'd also like to avoid having more *.java.in files than
absolutely necessary.

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

Yes, they are still available. The AWTCallbackHandler may not work
properly without a peer implementation, but that should be the concern
of the person disabling the native peers. For example, the user may want
to supply their own peer implementation, instead of GNU classpath's
implementations.

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

I'd prefer to see all tests go into Mauve. It is much easier to use than
 runtime/library specific test suites, as anyone who has tried to run
kaffe with libgcj's test suite or vice versa can confirm, I guess :)

>
> 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, Casey!

cheers,
dalibor topic


_______________________________________________
Classpath mailing list
Classpath@...
http://lists.gnu.org/mailman/listinfo/classpath