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
pgp2uxCEdYYl2.pgp
Description: PGP signature
_______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath