|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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 thefollowing (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 anothergnu.classpath.crypto package hierarchy consisting of the following (GNUCrypto) 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 thesecond 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 bere-written as templates conditioned by existing Classpath configurationoption(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 sourcefolder in gnu.classpath.crypto.javax package that provides the additional strong stuff.* create a new source folder named 'junit' which will contain the JUnittest 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 ofcommits: 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
[Home] [Gnu Classpath] [Linux Kernel] [Linux Cryptography] [Fedora] [Fedora Directory] [Red Hat Development] [Red Hat 9 Bible] [Fedora Bible] [Red Hat 9] [Network Security Reading]