Re: Exporting the private key from gnu keystore

[Raif S. Naffah]

hello Felix,

On Wed May 30 2007 21:14:28 Felix Seeger wrote:
> ...
> I created a key/csr with keytool. Since Debian installed keytool in a $PATH
> directory I have used gnu keytool which Sun Java cannot use...
>
> Is there way to convert the keystore into the sun format,

i don't know of such tools.


> or can I export 
> my data and import it again into a new keystore from sun ?

yes.  try the -export command with the (GNU) keytool using the -rfc option.


> I already tried to get the key with keystore.getKey(alias, password). I am
> not sure if that is correct, as I wasn't able to import it or use it in the
> sun keystore.
>
>
> Thanks a lot
> Felix


cheers;
rsn
-- 
cheers;
rsn


pgpzkNeTgZVum.pgp
Description: PGP signature

Re: gkeytool error

[Raif S. Naffah]

On Friday 20 October 2006 19:35, Haoyang Lin wrote:
> ...
> I did the same as you said. but the errors are still the same as before
>
> errors:
>
>  java.lang.NoClassDefFoundError: gnu/classpath/tools/keytool/Main
> <>
>  Caused by: java.lang.ClassNotFoundException:
>  gnu.classpath.tools.keytool.Main not found in java.lang.ClassLoader
>
> $1{urls=[file:/usr/local/classpath/share/classpath/glibj.zip,file:/usr/loca
>l/classpath/bin/./,file:/usr/local/classpath/share/classpath/tools.zip],
> parent=null} at java.net.URLClassLoader.findClass(URLClassLoader.java:530)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:342)
> at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:294)

gkeytool (in the directory Mario indicated) should be a script.  what does the 
last line in that file look like?


cheers;
rsn


pgpLid6QnLyZa.pgp
Description: PGP signature

Re: possible problem with gcjh (long)

[Raif S. Naffah]

hello Tom,

On Thursday 07 September 2006 08:43, Tom Tromey wrote:
> >>>>> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
> ...
> Raif> $ /opt/jdk1.5.0_08/bin/javah -jni -classpath . -o OC_IC.h OC$IC
>
> I'd guess that javah is also reading inner classes... gcjh will
> probably never do this, I'm afraid, but we should probably modify the
> javah in Classpath to be compatible here.  That shouldn't be hard.
> Could you file a PR?

since gcjh does not genrate the right header, while gjavah does so, any 
ideas/suggestions on how to fit gjavah into the build cycle?


cheers;
rsn


pgpmpO71iWKOu.pgp
Description: PGP signature

Re: native methods in inner classes (long)

[Raif S. Naffah]

On Thursday 21 September 2006 06:43, Robert Lougher wrote:
> On 9/20/06, Robert Lougher <[EMAIL PROTECTED]> wrote:
> > Anyway, I'll check a patch in for JamVM tonight.
>
> Committed...

and it works!

thanks + cheers;
rsn


pgpuQR8oHuNjo.pgp
Description: PGP signature

Re: native methods in inner classes (long)

[Raif S. Naffah]

On Wednesday 20 September 2006 07:36, Christian Thalinger wrote:
> On Tue, 2006-09-19 at 23:08 +0200, Christian Thalinger wrote:
> > On Wed, 2006-09-20 at 06:02 +1000, Raif S. Naffah wrote:
> > > * with both cacao and jamvm, even with the second signature, running
> > > the code causes an UnsatisfiedLinkError to be raised.
> >
> > That's completely right.  gcj can handle it correctly, AFAICT.  I'm
> > currently fixing this.
>
> Ok, I've commited a patch (thanks go to gcj).

works like a charm!

thanks + cheers;
rsn


pgp9wvNmmYQ4G.pgp
Description: PGP signature

Re: Classpath and gnu-crypto

[Raif S. Naffah]

hello Daniel,

On Wednesday 20 September 2006 03:35, Daniel Franganillo wrote:
> ...
> 1 - Class:
> import java.security.KeyPairGenerator;
> import java.security.NoSuchAlgorithmException;
> import java.security.KeyPair;
> import java.security.Security;
> import gnu.crypto.key.rsa.RSAKeyPairGenerator;
> import gnu.crypto.key.rsa.GnuRSAKey;

if you're using a recent GNU Classpath bundle, try replacing the last two 
import statements with:

import gnu.java.security.key.rsa.RSAKeyPairGenerator;
import gnu.java.security.key.rsa.GnuRSAKey;


cheers;
rsn


pgpljq9N34Rir.pgp
Description: PGP signature

native methods in inner classes (long)

[Raif S. Naffah]

hello all,

(this concerns VM implementers so i'm posting it here since it may relate to 
VMs other than the two i use for my testing)

since Jeroen F.'s comments on my recent BigInteger/GMP patch, i've been 
playing with having an inner class in BigInteger which has all the native 
methods.  the pattern is similar to the class OC (attached).

having thought i overcame a bug in how our gjavah generates the header files, 
i tried running the resulting code with both cacao and jamvm but i kept 
getting an UnsatisfiedLinkError.  i then tried the same code with both RIs 
1.4 (1.4.2_12) and 1.5 (1.5.0_08) using a rudimentary Makefile (attached).  
the results are interesting:

* the header file generated by the RI-1.5 emits a signature for the native 
method of an inner class that looks like so:

   JNIEXPORT void JNICALL Java_OC_IC_natInit

* the one for RI-1.4 looks like so:

  JNIEXPORT void JNICALL Java_OC_00024IC_natInit

* coding the native code (.c file attached) with the first signature and 
generating the .so library cause an UnsatisfiedLinkError with both RIs.

* coding with the second signature etc... works OK!

* with both cacao and jamvm, even with the second signature, running the code 
causes an UnsatisfiedLinkError to be raised.

* i haven't tried with ikvm, but an email from JF 
(http://sourceforge.net/mailarchive/message.php?msg_id=20565848) suggests 
that ikvm knows how to mangle the names before calling native methods of 
inner classes.


my questions are:

1. do VMs handle differently native method names depending on whether they are 
defined in an inner class or not?

2. should VMs handle native method calls for inner classes the same way as the 
RI?


TIA + cheers;
rsn
public class OC {
	static {
		System.loadLibrary("dummy");
		System.out.println("*** Loaded native library...");
	}

	transient IC _ic;

	OC() {
		super();
		_ic = new IC();
	}

	public static final void main(String[] args) {
		new OC();
	}

	private static final class IC {
		int np;

		IC() {
			super();
			natInit();
		}

		native void natInit();
	}
}

JAVA_HOME=/opt/j2sdk1.4.2_12
#JAVA_HOME=/opt/jdk1.5.0_08
JAVA=${JAVA_HOME}/bin/java
JAVAC=${JAVA_HOME}/bin/javac
JAVAH=${JAVA_HOME}/bin/javah
JAVA_LIBRARY_PATH=${JAVA_HOME}/jre/lib/i386/server:${JAVA_HOME}/jre/lib/i386:${JAVA_HOME}/lib/i386
CACAO=/data/workspace/cvs/classpath/install/bin/cacao
JAMVM=/data/workspace/cvs/classpath/install/bin/jamvm

class:
	${JAVAC} -classpath . OC.java

## with jdk 1.4 this has to be done on the command line; i.e.
##  # /opt/j2sdk1.4.2_12/bin/javah -classpath . -o OC_IC.h OC\$IC
jni:
	${JAVAH} -classpath . -o OC_IC.h OC$$IC
#	${JAVAH} -classpath . -d . OC$$IC

lib:
	gcc -fPIC -g -c -Wall OC_IC.c
	gcc -I/usr/local/java/include -I/usr/local/java/include/linux -shared -Wl,-soname,libdummy.so -o libdummy.so OC_IC.o -lc

run:
	${JAVA} -classpath . -Djava.library.path=.:${JAVA_LIBRARY_PATH} OC
#	${CACAO} -classpath . -Djava.library.path=.:${JAVA_LIBRARY_PATH} OC
#	${JAMVM} -classpath . -Djava.library.path=.:${JAVA_LIBRARY_PATH} OC

#include "OC_IC.h"
#include 


JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM *jvm __attribute__ ((__unused__)), void *reserved __attribute__ ((__unused__)))
{
  fprintf(stderr, "*** Loading dummy native library...\n");
  return (JNI_VERSION_1_2);
}

/* Java_OC_IC_natInit(JNIEnv *env  __attribute__ ((__unused__)), jobject this __attribute__ ((__unused__))) */
JNIEXPORT void JNICALL
Java_OC_00024IC_natInit(JNIEnv *env  __attribute__ ((__unused__)), jobject this __attribute__ ((__unused__)))
{
  printf("*** ...natInit() not implemented\n");
  return;
}


pgpLCeVWQbuP1.pgp
Description: PGP signature

Re: possible problem with gcjh (long)

[Raif S. Naffah]

On Friday 08 September 2006 02:58, Tom Tromey wrote:
> >>>>> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
>
> Raif> i'm attaching an OC$.java source and the generated header using
> Raif> gcjh.  same behaviour --the dollar symbol is replaced by its
> Raif> unicode codepoint.
>
> Could you send the header file that the JDK's javah creates for this
> class?  I'm curious about that.

i'm attaching three files, the first (with one underscore suffix) was 
generated by 1.4.2 with a -d option, and the second (with two underscores 
suffix) was generated with 1.5.0.

the third file was generated with gcjh (4.1.1 20060525 (Red Hat 4.1.1-1)).

in all files the native method name has the dollar symbol replaced with its 
unicode codepoint equivalent.


cheers;
rsn
/* DO NOT EDIT THIS FILE - it is machine generated */
#include 
/* Header for class OC_ */

#ifndef _Included_OC_
#define _Included_OC_
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class: OC_
 * Method:natInit
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_OC_00024_natInit
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif
/* DO NOT EDIT THIS FILE - it is machine generated */
#include 
/* Header for class OC__ */

#ifndef _Included_OC__
#define _Included_OC__
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class: OC__
 * Method:natInit
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_OC_00024_natInit
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif
/* DO NOT EDIT THIS FILE - it is machine generated */

#ifndef __OC$__
#define __OC$__

#include 

#ifdef __cplusplus
extern "C"
{
#endif

JNIEXPORT void JNICALL Java_OC_00024_natInit (JNIEnv *env, jobject);

#ifdef __cplusplus
}
#endif

#endif /* __OC$__ */


pgpOiv2dSt3WW.pgp
Description: PGP signature

Re: possible problem with gcjh (long)

[Raif S. Naffah]

On Thursday 07 September 2006 08:43, Tom Tromey wrote:
> >>>>> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
>
> Raif> $ gcjh -jni -classpath . -o OC_IC.h OC$IC
>
> ...
> Try OC\$IC and you will get a different result.

indeed.


> Raif> $ /opt/jdk1.5.0_08/bin/javah -jni -classpath . -o OC_IC.h OC$IC
>
> I'd guess that javah is also reading inner classes... gcjh will
> probably never do this, I'm afraid, but we should probably modify the
> javah in Classpath to be compatible here.  That shouldn't be hard.
> Could you file a PR?...

no problems.


> Raif> JNIEXPORT void JNICALL Java_OC_IC_natInit
>
> Hmm, gcjh generates Java_OC_00024IC_natInit.
> I'm surprised by the above, I (obviously I suppose :) would have
> picked the gcjh interpretation instead.
>
> Perhaps some experimentation is in order... what happens if you have a
> class with an explicit '$' in its name that has a native method?

i'm attaching an OC$.java source and the generated header using gcjh.  same 
behaviour --the dollar symbol is replaced by its unicode codepoint.

thanks for your prompt reply + cheers;
rsn
public class OC$
{
	OC$() {
		super();
		natInit();
	}

	native void natInit();
}/* DO NOT EDIT THIS FILE - it is machine generated */

#ifndef __OC$__
#define __OC$__

#include 

#ifdef __cplusplus
extern "C"
{
#endif

JNIEXPORT void JNICALL Java_OC_00024_natInit (JNIEnv *env, jobject);

#ifdef __cplusplus
}
#endif

#endif /* __OC$__ */


pgpMkfemVctOi.pgp
Description: PGP signature

possible problem with gcjh (long)

[Raif S. Naffah]

hello there,

i'm trying to generate the header file for a java class using:

$ gcjh --version
gcjh (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)...
$ gcjh -jni -classpath . -o OC_IC.h OC$IC

but i get an (almost) empty file (OC_IC.h.1).  using javah (JDK5), with the 
following command, i get what i expect (OC_IC.h.2):

$ /opt/jdk1.5.0_08/bin/javah -jni -classpath . -o OC_IC.h OC$IC


the class (OC.java) was compiled with ecj:

$ ecj -version
Eclipse Java Compiler v_585_R31x, 3.1.2 release...
$ ecj -source 1.4 -target 1.4 -cp . OC.java


nothing in GCC Bugzilla indicates a known problem for this case.  can somebody 
with a GCC/GCJ built from the current CVS HEAD confirm if the behaviour has 
changed.

TIA + cheers;
rsn
/* DO NOT EDIT THIS FILE - it is machine generated */

#ifndef __OC__
#define __OC__

#include 

#ifdef __cplusplus
extern "C"
{
#endif


#ifdef __cplusplus
}
#endif

#endif /* __OC__ */
/* DO NOT EDIT THIS FILE - it is machine generated */
#include 
/* Header for class OC */

#ifndef _Included_OC
#define _Included_OC
#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif
#endif
/* Header for class OC_IC */

#ifndef _Included_OC_IC
#define _Included_OC_IC
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class: OC_IC
 * Method:natInit
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_OC_IC_natInit
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif
public class OC
{
  transient IC _ic;

  OC()
  {
super();
_ic = new IC();
  }

  private static final class IC
  {
int np;

IC()
{
  super();
  natInit();
}

native void natInit();
  }
}

pgpxMHKOKPfQu.pgp
Description: PGP signature

Re: SIGSEGV caused by libgconf-2.so.4

[Raif S. Naffah]

ciao Mario,

On Saturday 05 August 2006 02:22, Mario Torre wrote:
> Il giorno ven, 04/08/2006 alle 22.48 +1000, Raif S. Naffah ha scritto:
> >
> >   --enable-default-preferences-peer=peer type or class name
> >   specify one of: "gconf" [default] for a GConf
> > based backend, "file" for a file based one, "memory" for a transient one,
> > or a fully qualified class name implementing
> > java.util.prefs.PreferencesFactory
> >
> > ...
> Seems fine to me.
>
> Can you please send this patch to classpath-patches with RFC for review?

done!

thanks + cheers;
rsn


pgpaReKsUQsVs.pgp
Description: PGP signature

Re: SIGSEGV caused by libgconf-2.so.4

[Raif S. Naffah]

ciao Mario,

On Friday 04 August 2006 20:29, Mario Torre wrote:
> ...
> For the configure patch (any non trivial commit), I need approval so I
> have not committed it also.
>
> I wait feedback :)

i'm attaching another alternative to the default-preferences-peer option which 
covers all existing three alternatives for the preferences factory 
implementation we already have, plus allows for different/new ones if we 
decide not to refer to them symbolically.

i tested configure:

* without the option altogether,
* with just enable-default-preferences-peer,
* with enable-default-preferences-peer=file, and
* with enable-default-preferences-peer=gnu.java.util.prefs.MemoryBasedFactory

and they all do the right thing; i.e. the java.utils.prefs.PreferencesFactory 
file in META-INF/services/ contains the correct class name.

the help string makes it clear what the acceptable values for this option are:

  --enable-default-preferences-peer=peer type or class name
  specify one of: "gconf" [default] for a GConf based
  backend, "file" for a file based one, "memory" for a
  transient one, or a fully qualified class name
  implementing java.util.prefs.PreferencesFactory


cheers;
rsn
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.176
diff -u -r1.176 configure.ac
--- configure.ac	2 Aug 2006 23:28:12 -	1.176
+++ configure.ac	4 Aug 2006 12:34:18 -
@@ -85,13 +85,16 @@
 dnl ---
 dnl Default Preference Backend
 dnl ---
-AC_ARG_ENABLE(default-preferences-peer,
-  AS_HELP_STRING([--enable-default-preferences-peer],
- [fully qualified class name of default Preferences API Backend]))
-DEFAULT_PREFS_PEER=$enable_default_preferences_peer
-if test "$DEFAULT_PREFS_PEER" = ""; then
-   DEFAULT_PREFS_PEER=gnu.java.util.prefs.FileBasedFactory
-fi
+AC_ARG_ENABLE([default-preferences-peer],
+  [AS_HELP_STRING([--enable-default-preferences-peer[=peer type or class name]],
+  [specify one of: "gconf" [default] for a GConf based backend, "file" for a file based one, "memory" for a transient one, or a fully qualified class name implementing java.util.prefs.PreferencesFactory])],
+  [case "${enableval}" in
+file) DEFAULT_PREFS_PEER=gnu.java.util.prefs.FileBasedFactory  ;;
+gconf) DEFAULT_PREFS_PEER=gnu.java.util.prefs.GConfBasedFactory  ;;
+memory) DEFAULT_PREFS_PEER=gnu.java.util.prefs.MemoryBasedFactory  ;;
+*) DEFAULT_PREFS_PEER=${enableval} ;;
+  esac],
+  [DEFAULT_PREFS_PEER=gnu.java.util.prefs.GConfBasedFactory])
 dnl AC_SUBST(DEFAULT_PREFS_PEER)

 dnl ---

Re: SIGSEGV caused by libgconf-2.so.4

[Raif S. Naffah]

hello Mario,

On Friday 04 August 2006 11:09, Raif S. Naffah wrote:
> On Friday 04 August 2006 10:53, Mario Torre wrote:
> > Il giorno ven, 04/08/2006 alle 10.13 +1000, Raif S. Naffah ha scritto:
> > > On Friday 04 August 2006 09:49, Raif S. Naffah wrote:
> > > > On Friday 04 August 2006 09:32, Mario Torre wrote:
> > > > > Il giorno ven, 04/08/2006 alle 09.12 +1000, Raif S. Naffah ha scritto:
> > > > > > i'm getting a segmentation fault caused by
> > > > > > /usr/lib/libgconf-2.so.4 (FC5) when trying to run jamvm with
> > > > > > Classpath (both CVS Head)... anybody else is seeing this?
> > > > >
> > > > > Do you have a test case for that?
> > > >
> > > > here is how i can trigger it:
> > > >
> > > > import java.util.prefs.Preferences;
> > > >
> > > > public class Hello {
> > > >   public static final void main(String[] args) {
> > > > Preferences prefs =
> > > > Preferences.systemNodeForPackage(Hello.class); int lastSerialNumber =
> > > > prefs.getInt("LAST_SERIAL_NUMBER", 0) + 1;
> > > > prefs.putInt("LAST_SERIAL_NUMBER", lastSerialNumber);
> > > >   }
> > > > }
> >
> > I can't reproduce.
> >
> > Moreover, you get a warning if you put this into the default package (it
> > does not cause harm), but other than that, it is fine (the warning is
> > normal).
> >
> > Anyway, Can you try the attached patch and see if it works?
>
> i'll do that soon.

it does!  as you mentioned, i do get the following printed to the console, but
otherwise the program functions as expected:

(process:18806): GConf-CRITICAL **: gconf_client_add_dir: assertion 
`gconf_valid_key (dirname, NULL)' failed


thanks for your prompt intervention + cheers;
rsn


pgpWa6tfYw4mD.pgp
Description: PGP signature

Re: SIGSEGV caused by libgconf-2.so.4

[Raif S. Naffah]

On Friday 04 August 2006 10:53, Mario Torre wrote:
> Il giorno ven, 04/08/2006 alle 10.13 +1000, Raif S. Naffah ha scritto:
> > On Friday 04 August 2006 09:49, Raif S. Naffah wrote:
> > > On Friday 04 August 2006 09:32, Mario Torre wrote:
> > > > Il giorno ven, 04/08/2006 alle 09.12 +1000, Raif S. Naffah ha scritto:
> > > > > i'm getting a segmentation fault caused by /usr/lib/libgconf-2.so.4
> > > > > (FC5) when trying to run jamvm with Classpath (both CVS Head)...
> > > > > anybody else is seeing this?
> > > >
> > > > Do you have a test case for that?
> > >
> > > here is how i can trigger it:
> > >
> > > import java.util.prefs.Preferences;
> > >
> > > public class Hello {
> > >   public static final void main(String[] args) {
> > > Preferences prefs = Preferences.systemNodeForPackage(Hello.class);
> > > int lastSerialNumber = prefs.getInt("LAST_SERIAL_NUMBER", 0) + 1;
> > > prefs.putInt("LAST_SERIAL_NUMBER", lastSerialNumber);
> > >   }
> > > }
>
> I can't reproduce.
>
> Moreover, you get a warning if you put this into the default package (it
> does not cause harm), but other than that, it is fine (the warning is
> normal).
>
> Anyway, Can you try the attached patch and see if it works?

i'll do that soon.


> > in addition to the above, when i configure Classpath with
> > --disable-default-preferences-peer, and try to run the same code (as
> > above) i get:
>
> Well, sorry this is my fault, I hope to fix this tomorrow, as I'm not an
> autoconf expert, so I have to look at it in more details (and now I
> really need some sleep).
>
> There should not be any --disable-default-preferences-peer.
>
> The preference flags are intended to use this way:
>
> --disable-gconf-peer: disable the gconf backend
> --enable-default-preferences-peer=gnu.java.util.prefs.FileBasedFactory:
> use another backend, not the default (everything that this default is,
> may also not be gconf).

i'm attaching a patch that fixes this configuration issue.


> This means that you can build the preference backend but with another
> default, or you can totally disable the preference backend.
>
> I guess that --disable-default-preferences-peer should not create any
> key in the META-INF directory.
>
> The correct name for this flag should really be
> --with-default-preferences-peer...
>
> The exceptions are normal, it should revert to a sane default if
> everything else fails. This should be the FileBasedPreferences, can you
> please confirm this? What happened after the error?

as i mentioned earlier a seg fault; i.e. the VM exists.


> Sorry for the confusion, and thanks for pointing me out to this

no worries!  thanks for looking into it.


cheers;
rsn
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.176
diff -u -r1.176 configure.ac
--- configure.ac	2 Aug 2006 23:28:12 -	1.176
+++ configure.ac	4 Aug 2006 01:00:03 -
@@ -85,13 +85,15 @@
 dnl ---
 dnl Default Preference Backend
 dnl ---
-AC_ARG_ENABLE(default-preferences-peer,
-  AS_HELP_STRING([--enable-default-preferences-peer],
- [fully qualified class name of default Preferences API Backend]))
-DEFAULT_PREFS_PEER=$enable_default_preferences_peer
-if test "$DEFAULT_PREFS_PEER" = ""; then
-   DEFAULT_PREFS_PEER=gnu.java.util.prefs.FileBasedFactory
-fi
+AC_ARG_ENABLE([default-preferences-peer],
+  [AS_HELP_STRING([--enable-default-preferences-peer],
+  [fully qualified class name of default Preferences API Backend [default=gnu.java.util.prefs.GConfBasedFactory])])],
+  [case "${enableval}" in
+yes) DEFAULT_PREFS_PEER=gnu.java.util.prefs.GConfBasedFactory  ;;
+no) DEFAULT_PREFS_PEER=gnu.java.util.prefs.FileBasedFactory  ;;
+*) DEFAULT_PREFS_PEER=${enableval} ;;
+  esac],
+  [DEFAULT_PREFS_PEER=gnu.java.util.prefs.GConfBasedFactory])
 dnl AC_SUBST(DEFAULT_PREFS_PEER)

 dnl ---

Re: SIGSEGV caused by libgconf-2.so.4

[Raif S. Naffah]

On Friday 04 August 2006 09:49, Raif S. Naffah wrote:
> On Friday 04 August 2006 09:32, Mario Torre wrote:
> > Il giorno ven, 04/08/2006 alle 09.12 +1000, Raif S. Naffah ha scritto:
> > > i'm getting a segmentation fault caused by /usr/lib/libgconf-2.so.4
> > > (FC5) when trying to run jamvm with Classpath (both CVS Head)...
> > > anybody else is seeing this?
> >
> > Do you have a test case for that?
>
> here is how i can trigger it:
>
> import java.util.prefs.Preferences;
>
> public class Hello {
>   public static final void main(String[] args) {
> Preferences prefs = Preferences.systemNodeForPackage(Hello.class);
> int lastSerialNumber = prefs.getInt("LAST_SERIAL_NUMBER", 0) + 1;
> prefs.putInt("LAST_SERIAL_NUMBER", lastSerialNumber);
>   }
> }

in addition to the above, when i configure Classpath with
--disable-default-preferences-peer, and try to run the same code (as
above) i get:

Aug 4, 2006 10:06:25 AM gnu.classpath.ServiceFactory lookupProviders
WARNING: Cannot load service provider class "no", specified by 
"META-INF/services/java.util.prefs.PreferencesFactory" in 
file:/data/workspace/cvs/classpath/install/share/classpath/META-INF/services/java.util.prefs.PreferencesFactory
java.security.PrivilegedActionException: java.lang.ClassNotFoundException: no 
not found in java.lang.ClassLoader$1{urls=[file:/home/raif/], parent=null}
   at java.security.AccessController.doPrivileged(AccessController.java:203)
   at 
gnu.classpath.ServiceFactory$ServiceIterator.loadNextServiceProvider(ServiceFactory.java:463)
   at 
gnu.classpath.ServiceFactory$ServiceIterator.(ServiceFactory.java:372)
   at gnu.classpath.ServiceFactory.lookupProviders(ServiceFactory.java:252)
   at java.util.prefs.Preferences.getFactory(Preferences.java:214)
   at java.util.prefs.Preferences.systemRoot(Preferences.java:139)
   at java.util.prefs.Preferences.systemNodeForPackage(Preferences.java:257)
   at Hello.main(Hello.java:5)
Caused by: java.lang.ClassNotFoundException: no not found in 
java.lang.ClassLoader$1{urls=[file:/home/raif/], parent=null}
   at java.net.URLClassLoader.findClass(URLClassLoader.java:531)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:342)
   at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
   at 
gnu.classpath.ServiceProviderLoadingAction.run(ServiceProviderLoadingAction.java:139)
   at java.security.AccessController.doPrivileged(AccessController.java:195)
   ...7 more


which i presume is caused by "no" being generated in the file
java.util.prefs.PreferencesFactory under resource/META-INF/services,
instead of "gnu.java.util.prefs.FileBasedFactory".


cheers;
rsn


pgpbJWpNiZJ4v.pgp
Description: PGP signature

Re: SIGSEGV caused by libgconf-2.so.4

[Raif S. Naffah]

hello Mario,

On Friday 04 August 2006 09:32, Mario Torre wrote:
> Il giorno ven, 04/08/2006 alle 09.12 +1000, Raif S. Naffah ha scritto:
> > i'm getting a segmentation fault caused by /usr/lib/libgconf-2.so.4
> > (FC5) when trying to run jamvm with Classpath (both CVS Head)...
> > anybody else is seeing this?
>
> Hi!
> Do you have a test case for that?
>
> I can't see it, but maybe I'm trying with the wrong tests...

here is how i can trigger it:

import java.util.prefs.Preferences;

public class Hello {
  public static final void main(String[] args) {
Preferences prefs = Preferences.systemNodeForPackage(Hello.class);
int lastSerialNumber = prefs.getInt("LAST_SERIAL_NUMBER", 0) + 1;
prefs.putInt("LAST_SERIAL_NUMBER", lastSerialNumber);
  }
}

compiled with javac:

$ javac -version
Eclipse Java Compiler v_585_R31x, 3.1.2 release, Copyright IBM Corp 2000, 
2006. All rights reserved.

and run with jamvm:

$ ./bin/jamvm -version
java version "1.4.2"
JamVM version 1.4.4-pre
...


cheers;
rsn


pgprv0ZKkCI67.pgp
Description: PGP signature

SIGSEGV caused by libgconf-2.so.4

[Raif S. Naffah]

hello all,

i'm getting a segmentation fault caused by /usr/lib/libgconf-2.so.4
(FC5) when trying to run jamvm with Classpath (both CVS Head):

(process:20336): GLib-GObject-CRITICAL **: gtype.c:2215: initialization 
assertion failed, use IA__g_type_init() prior to this function

(process:20336): GLib-GObject-CRITICAL **: g_object_new: assertion 
`G_TYPE_IS_OBJECT (object_type)' failed

(process:20336): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT 
(object)' failed


the crash occurs in GConfNativePeer.c on line 554:

 static void init_gconf_client (void)
 {
-->client = gconf_client_get_default ();
   g_type_init ();
 }

anybody else is seeing this?


cheers;
rsn


pgp0Fsa2pEYgl.pgp
Description: PGP signature

Re: RSA-OAEP support in classpath-crypto

[Raif S. Naffah]

hello John.

On Tuesday 11 July 2006 00:23, John Pritchard wrote:
> hi raif,
>
> >> Having a look at Pads again last night, there's no way for a Pad
> >> to get configured
> >
> > we can also add an additional initialisation method --init(Map
> > attributes)-- to the padding interface to cater for this new types
> > of padders.
>
> i'm hoping you're going to do this, account for design implications
> past and present, etc..  i just checked cvs and didnt see it in
> `ipad'. ..

no problems.  just give me a couple of hours.


>
> >> --- which would be why the last one came out a mode.
> >
> > what last one?
>
> yes, the oae

ok.  do you think it's worth it, adding an AONT mode to the library?


cheers;
rsn


pgpmNUq0vw3MD.pgp
Description: PGP signature

Re: RSA-OAEP support in classpath-crypto

[Raif S. Naffah]

hello John,

On Thursday 06 July 2006 23:04, John Pritchard wrote:
> ...
> Having a look at Pads again last night, there's no way for a Pad to
> get configured

the only attribute that can currently be configured on an IPad is the 
pad block size.  usually when an algorithm of a certain type offers 
more configuration options than what the type interface offers, these 
are handled by algorithm-specific methods; e.g. Haval and 
IMessageDigest.

we can also add an additional initialisation method --init(Map 
attributes)-- to the padding interface to cater for this new types of 
padders.


> --- which would be why the last one came out a mode.

what last one?


> John
>
> >>> Hi,
> >>>
> >>> The OAE that I submitted is different from the EOAE for RSA
> >>> padding.
> >>>
> >>> I have some EOAE code not yet ported to classpath like OAE,
> >>> http://www.syntelos.com/src/com/syntelos/foam/EOAE.java.html
> >>>
> >>> I could do this soonly.
> >>
> >> That would be excellent! This is a high priority for me, so again,
> >> if you need help, please let me know.


cheers;
rsn


pgpPmCPmZ0Csk.pgp
Description: PGP signature

Re: [cp-patches] FYI: X peers

[Raif S. Naffah]

hello Michael,

On Saturday 01 July 2006 20:05, Michael Koch wrote:
> On Sat, Jul 01, 2006 at 10:33:10AM +0200, Roman Kennke wrote:
> > Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah:
> > > On Friday 30 June 2006 01:27, Roman Kennke wrote:
> > > > I checked in the Escher-based X peers and added some configury
> > > > for enabling it. To build the X peers you need the most recent
> > > > Escher library, to be found here:
> > > >
> > > > http://kennke.org/~roman/escher-0.3.0.jar
> > > >
> > > > Configure with: --with-escher=/path/to/escher-0.3.0.jar
> > > > --enable-local-sockets
> > >
> > > would it make sense to create a new folder, say "external-jars"
> > > and include the latest escher (and other java-only external
> > > dependencies) jar(s) there.  --with-escher can use that
> > > jar/location by default, otherwise the full path to a
> > > distro's/user's location of that jar can be fed to configure.
> >
> > This makes sense. I am all for it.
> >
> > Mark proposed to put jars that are (optionally) needed for
> > classpath on http://builder.classpath.org/ somewhere. What do
> > others think?
>
> Don't put jars without sources into classpath releases. Otherwise
> Distros will need to alter the upstream tarball and remove this. And
> altering removes the feature that people can easily check if the
> upstream sources used by a distro is really what upstream released.

would including the jar of the sources --e.g. escher-0.3.0.jar and 
escher-0.3.0-src.jar-- address that concern.


cheers;
rsn


pgpMCTxdlwulF.pgp
Description: PGP signature

Re: diffie-hellman problem

[Raif S. Naffah]

hello Christian,

On Thursday 29 June 2006 01:07, Christian Thalinger wrote:
> On Tue, 2006-06-27 at 21:27 +1000, Raif S. Naffah wrote:
> > found the problem;  should be able to check-in a fix within the
> > next 48h.
>
> Very cool!  Thanks for the quick fix.  Does this Sun demo now work
> for you?  It does not throw the exception anymore, but it hangs here
> with 0% cpu:
>
> 
> Shared secrets are the same
> Return shared secret as SecretKey object ...
> DES in ECB mode recovered text is same as cleartext
> DES in CBC mode recovered text is same as cleartext

i test against the Mauve testlet and this is what i get:

TEST: gnu.javax.crypto.jce.TestOfDHKeyAgreement2
*** Generating Alice's Diffie-Hellman key-pair
*** Initializing Alice's Diffie-Hellman key-agreement
*** Alice sends Bob her encoded key...
*** Generating Bob's Diffie-Hellman key-pair
*** Initializing Bob's Diffie-Hellman key-agreement
*** Bob sends Alice his encoded key...
*** Alice does phase #1
*** Bob does phase #1
  pass:  line 160: generateSecret(byte[128], 1) MUST throw ShortBufferException 
[1]
  pass:  line 165: Shared secrets MUST be equal [1]
*** Bob generates a new shared secret
*** Alice generates a new shared secret
*** Bob sends Alice a DES/ECB encrypted message
  pass:  line 190: DES/ECB recovered text and cleartext MUST be equal [1]
*** Bob sends Alice a DES/CBC encrypted message
  pass:  line 209: DES/CBC recovered text and cleartext MUST be equal [1]
TEST PASSED (4 checks) gnu.javax.crypto.jce.TestOfDHKeyAgreement2

TEST RESULTS:
0 of 1 tests failed.  0 total calls to harness.check() failed.

with:

* Classpath CVS HEAD, configured --with-jikes
* the latest JamVM, checked out from cvs.jamv.berlios.de.
$ jamvm -version
java version "1.4.2"
JamVM version 1.4.4-pre
Copyright (C) 2003-2006 Robert Lougher <[EMAIL PROTECTED]>
* Harness invoked with -showpasses -verbose


the fact that it hangs after, presumably, the last crypto operation is
indicative of a thread or VM related problem, but i could be wrong.


> jamvm crashes on my x86_64, so I don't know if that's a cacao bug.

Robert should be able to help with this.


> Another thing is, it didn't fix the problem in this proprietary
> application I'm trying to run.  I'll paste the stacktrace, maybe you
> have an idea:
>
> java.security.spec.InvalidKeySpecException: Unexpected OID:
> 1.3.14.3.2.12 at
> gnu.java.security.jce.sig.DSSKeyFactory.engineGeneratePublic(DSSKeyFa
>ctory.java:96) at
> java.security.KeyFactory.generatePublic(KeyFactory.java:219) at
> hox.corem.server.LicenseManagerImpl.(LicenseManagerImpl.java:
>89) Caused by: java.security.InvalidParameterException: Unexpected
> OID: 1.3.14.3.2.12 at
> gnu.java.security.key.dss.DSSKeyPairX509Codec.decodePublicKey(DSSKeyP
>airX509Codec.java:204) at
> gnu.java.security.jce.sig.DSSKeyFactory.engineGeneratePublic(DSSKeyFa
>ctory.java:91) ...2 more

this is indicative of a possible problem with the DSS/DSA JCE Adapters.
an example code/test-case, with the data that caused the exception,
would be a great help in finding the bug and validating the fix.


cheers;
rsn


pgpdzsUEHa8PD.pgp
Description: PGP signature

Re: diffie-hellman problem

[Raif S. Naffah]

hello Christian,

On Tuesday 27 June 2006 19:45, Christian Thalinger wrote:
> On Tue, 2006-06-27 at 19:35 +1000, Raif S. Naffah wrote:
> > i'll have a closer look at it and will let you know.
> >
> > btw.  i presume you're using the CVS HEAD?
>
> Yes, right.

found the problem;  should be able to check-in a fix within the next 
48h.


cheers;
rsn


pgputn5RaoAwe.pgp
Description: PGP signature

Re: diffie-hellman problem

[Raif S. Naffah]

hello Christian,

On Tuesday 27 June 2006 08:25, Christian Thalinger wrote:
> Hi!
>
> I'm trying to run an application which uses a lot of crypto stuff and
> I ran into some problems.  A friend of mine told me to try some
> tests, like this one:
>
> http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.ht
>ml#DH2Ex
>
> And actually it does not work with GNU Classpath. I get:
>
> $ cacao DHKeyAgreement2
> Using SKIP Diffie-Hellman parameters
> ALICE: Generate DH keypair ...
> ALICE: Initialization ...
> java.security.spec.InvalidKeySpecException
>at
> gnu.javax.crypto.jce.sig.DHKeyFactory.engineGeneratePublic(DHKeyFacto
>ry.java:94) at
> java.security.KeyFactory.generatePublic(KeyFactory.java:219) at
> DHKeyAgreement2.run(DHKeyAgreement2.java:107)
>at DHKeyAgreement2.main(DHKeyAgreement2.java:54)
> Caused by: java.lang.NumberFormatException
>at java.math.BigInteger.(BigInteger.java:156)
>at
> gnu.java.security.der.DERReader.readUniversal(DERReader.java:226) at
> gnu.java.security.der.DERReader.read(DERReader.java:165) at
> gnu.javax.crypto.key.dh.DHKeyPairX509Codec.decodePublicKey(DHKeyPairX
>509Codec.java:212) at
> gnu.javax.crypto.jce.sig.DHKeyFactory.engineGeneratePublic(DHKeyFacto
>ry.java:89) ...3 more
>
> Any ideas?

i'll have a closer look at it and will let you know.

btw.  i presume you're using the CVS HEAD?


cheers;
rsn


pgpjO8ie433kb.pgp
Description: PGP signature

Re: Crypto components as external JCE provider

[Raif S. Naffah]

hello Michael,

On Thursday 22 June 2006 21:24, Michael Koch wrote:
> On Thu, Jun 22, 2006 at 08:07:19PM +1000, Raif S. Naffah wrote:
> > On Thursday 22 June 2006 08:36, Vivek Lakshmanan wrote:
> > > ...
> > > 4) Code in these packages (especially the JCE provider packages)
> > > will only use Java 1.4.x constructs for the time being so it can
> > > be used with 1.4.x based JDKs (PR28127).
> >
> > does anybody know of a free tool that can help detect usage of
> > non-1.4 API in a package/jar?  could the JAPI tool be used for this
> > or as part of a solution?
>
> The eclipse compiler and building with -source 1.4 I would say...

yes!  this worked after some tweaking with the source folders and 
including the RI-1.4 rt.jar in the libraries to include in the project.

i'll update the PR with the list of errors detected by Eclipse.


thanks + cheers;
rsn


pgpgWvg9IPU6H.pgp
Description: PGP signature

Re: Crypto components as external JCE provider

[Raif S. Naffah]

On Thursday 22 June 2006 08:36, Vivek Lakshmanan wrote:
> Hi All,
> A few of us have been discussing extracting the crypto components in
> classpath as an external JCE provider especially for use with Java
> 1.4.x based VMs (PR27649 for those looking for the whole story). This
> will also help those trying to package classpath for distribution
> under export restrictions since these jars can be excluded much more
> easily than if they are integrated into the main classpath jar.
>
> What follows is a summary of what has been discussed so far. I feel
> it would be best to see if there are any reservations about our
> plans:
>
> 1) We are currently planning to produce a crypto provider jar
> (gnu.java.security, gnu.javax.crypto and gnu.javax.security).
> Currently there are some dependencies on 'gnu.classpath.debug'. One
> suggestion was to produce a separate jar for this package.  This
> sounds reasonable to me but are there any objections? The other minor
> dependencies on other classpath packages will be cleaned up.
>
> 2) We will extract a JCE jar with the javax.crypto classes. Most
> 1.4.x vendors now include these, however, they check to see if the
> provider is signed. This issue has been discussed earlier in various
> contexts [1]. If we produce this jar, users can use our crypto
> provider by placing the JCE jar in the endorsed directory of their
> JRE for instance (if they desire to do so).
>
> 3) A Jessie jar would be extracted in a similar manner.
>
> 4) Code in these packages (especially the JCE provider packages) will
> only use Java 1.4.x constructs for the time being so it can be used
> with 1.4.x based JDKs (PR28127).

does anybody know of a free tool that can help detect usage of non-1.4 
API in a package/jar?  could the JAPI tool be used for this or as part 
of a solution?


> All suggestions/comments are welcome.
> Thanks,
> Vivek
>
>
> [1] http://lists.debian.org/debian-java/2005/10/msg00089.html

TIA + cheers;
rsn


pgpoN76APbCWy.pgp
Description: PGP signature

Re: [crypto] OAEP AONT (gnu/javax/crypto/mode/OAE.java)

[Raif S. Naffah]

hello John,

On Saturday 17 June 2006 00:35, John Pritchard wrote:
> Raif,
>
> thanks for your comments.   the doc references have been linked,

thanks.

> the 
> Init links have been changed to Doc ones,

yes but that does not help!  linking @see references to anchors in the 
class's javadoc does not make my Eclipse any happier.  putting the bulk 
of the parameters' documentation with their declaration, and if still 
needed, linking to them --e.g. [EMAIL PROTECTED] #xxx} should fix this.

> the property strings 
> shortened for faster hashing time,

yes but i see you're still using a non-dotted name.  any strong reason 
to diverge from the existing convention?

> a couple new constructors added, 
> and a main for quick testing.

for testing we rely on Mauve, the companion project to GNU Classpath: 
.  the only testing requirement for 
the crypto classes is a self-test that validates the implementation.  
for block ciphers for example one KAT (Known Answer Text) is used.  no 
main() methods should be present in the algorithms.


other notes:

* i like the idea of using the null-cipher as the "default" cipher.  it 
highlights the fact that this mode can be used, on its own, as an 
All-Or-Nothing transform!

* shouldn't the following comment (in encryptBlock()) read:

   // T = (R xor H(M xor G(r)))
rather than
   // T = (R xor H( X xor G(r)))

* in computing T (in encryptBlock()) (and similarly for S in the same 
method, M, and r in decryptBlock()) wouldn't be cheaper to just do:

   T = R[idx] ^ Hx[idx];
   aont[aont_idx] = (byte) T;

* finally, in your final patch submission, please fix the imports and 
use the EFJ i mentioned in my earlier post.


> one question..
>
> has it been your intention that all assemblies would include a
> padding mode?

no;  the long explanation follows.

> a quick test as included here will likely show the 
> encode/decode cycle adding zero bits to the tail of the processed
> plaintext.  of course this is due to the i-block-cipher enc/dec
> methods presuming input (and output) is 'block size' (no length or
> block length delta).  it's not clear to me how an application
> generally avoids this modification of the plain text (without a
> padding mode).

all assemblies involving a block-cipher, once setup, will operate with a 
block-size.  this block-size may not be the same as the cipher's one, 
nevertheless it is block-based.  in this context if the input text size 
is not a multiple of the assembly's block size you have a problem.  you 
can still construct assemblies without padding algorithms if for 
example you use a mode with 1-byte block-size.  this is how 
block-ciphers can be turned into stream ciphers!  on the other hand, if 
the mode has a block-size > 1, the assembly must be fitted with a 
padding algorithm, so when the last push (of data) occurs into the 
assembly, it can/will produce the final block.

have a look at the gnu.javax.crypto.assembly classes and their Mauve 
tests to see how you can build and operate different kinds of 
constructs including a Blowfish-OFB-PKCS7-Zip cascade.


cheers;
rsn


pgpUNFDFs376y.pgp
Description: PGP signature

Re: [crypto] OAEP AONT (gnu/javax/crypto/mode/OAE.java)

[Raif S. Naffah]

hello John,

On Friday 16 June 2006 00:57, John Pritchard wrote:
> dear reader,
>
> attached is an OAEP AONT, ready for your comments or cvs

thanks for your contribution!

i do have some comments:

* it would be very helpful to include in the class documentation web 
references (HREFs) to cited documents and works the implementation is 
based on.  i believe all three cited references are available on the 
net.

* why not specify a default cipher, similar to H and R?  a 0-arguments 
constructor can then call the non-trivial constructor with the default 
block size of the _default_ cipher.

* is there other implementations of this scheme with published test 
vectors?  if not i think you should generate one such value and test 
for it in the self-test method.  a self-test relying solely on 
symmetric operation, especially with this type of mode is meaningless.

* property names, all (to my knowledge) start with "gnu.crypto" whatever 
package the classes using them, live in.  so INIT_H should read:

   gnu.crypto...

furthermore for property names, the lower-case, dotted form is generally 
preferred, unless it references a parameter described in the reference 
paper(s) of the algorithm;  hence acceptable names of INIT_H could be:

   gnu.crypto.oae.H
or
   gnu.crypto.oae.hash.name

(see the TMMH16 mac).

* InitHash, InitRand, and InitGenerator do not exist (anymore) --i 
suspect you had separate methods so named, and called from the init() 
method in a previous incarnation of this code.

* JavaDoc does not like OAE$Generator, Registry.SHA160_HASH.  
OAE.Generator and Registry#SHA160_HASH are ok.

* we don't qualify classes from the java.lang package, so for example 
writing String instead of java.lang.String is better.

* some other style inconsistencies which can be ironed out by using an 
Eclipse IDE (with the GNU style formatter if it does not already use it 
by default), or at least the Eclipse Formatter for Java 
().


cheers;
rsn

Re: Mauve reports

[Raif S. Naffah]

hello Roman,

On Friday 09 June 2006 00:13, Roman Kennke wrote:
> FYI: I have set up my old Mauve report script on
> builder.classpath.org to generate nice HTML for the Mauve results:
>
> http://builder.classpath.org/mauve/mauvereport.cgi

very useful.  thanks for doing this.


> This really is only a frontend to:
> http://builder.classpath.org/mauve/mauve-jamvm
>
> These results normally get updated continuously, so the frontend
> should always report the latest results that have been built
> sucessfully.
>
> In the future we will (hopefully) add more compiler/VM(/classlib)
> combinations so that we can compare the results to others.
>
> I welcome suggestions for improvements of this frontend.

* it wasn't clear to me if the Last update date, is local or UTC.
* what timeout value is used in the scripts?  i see that most of the 
failed tests are due to timeout.  since this is an automated build/test 
process, may be we can increase that limit.


cheers;
rsn


pgpnWc66a6X6C.pgp
Description: PGP signature

Re: GOST cipher & related added.

[Raif S. Naffah]

hello Morgon,

the first thing to do if you plan on contributing code to the project is 
to ensure that copyright assignment papers, for GNU Classpath, are 
signed.  i don't know if you have already done so, but in case you 
haven't, Mark Wielaard should be able to guide you in that process.

On Sunday 04 June 2006 19:50, Morgon Kanter wrote:
> Of course, this had to come at about the same time that Raif made a
> bunch of changes to various crypto-related files and scared the hell
> out of me thinking that I was suddenly going to have a merge
> conflict. :-P
>
> In general:
>
> The full output of cvs diff -uN classpath > blah is available here:
> http://www.surgo.net/classpath/cvsdiffoutput.diff
>
> For some reason, the -N option doesn't seem to be working so the
> additional files are all available here:
> http://www.surgo.net/classpath/GOST.java
> http://www.surgo.net/classpath/GOSTSpi.java
> http://www.surgo.net/classpath/GOSTKeyGeneratorImpl.java
> http://www.surgo.net/classpath/GOSTSecretKeyFactoryImpl.java
> http://www.surgo.net/classpath/OMacGOSTImpl.java
> (Where to put them is said in the top of the diff file, at least.)
>
>
> Sum of changes:
>
> * Complete addition of the GOST block cipher.
> * Addition of method addTwoUnsignedIntegers to Util.java
> * Addition of method copyIntToBytes to Util.java
> (More than one other file duplicates this functionality
> unnecessarily.) * Addition of method toIntFromBytes to Util.java
> (More than one other file duplicates this functionality
> unnecessarily.) * Making PBES2.java use only one coding style.
>
> I'll get to modifying the duplicates in the other files to use the
> new Util.java code one of these days, it didn't seem proper to put it
> in with this change.
>
>
> On my GOST implementation:

my understanding is that GOST is a family of standards that covers 
things other than crypto.  the symmetric block cipher, subject of a 
GOST standards is really "GOST 28147-89" (there's also a GOST hash 
algorithm! --GOST R 34.11-94)

i recommend you change the name to reflect this, and may be use "GOST" 
as an alias.


> I'd really like Casey or Raif or both to check this to make sure it
> actually works as it's supposed to. It decrypts what it encrypts, but
> testing to actually make sure that the encryption function works as
> it's supposed to is made quite difficult by the lack of official test
> vectors. It seems correct, everything is done exactly as described in
> Schneier's book and the translated spec, but looks can be deceiving
> and the lack of test vectors is a real pain. If it means anything,
> all of the implementation problems I had (stuff not decrypting
> correctly) were due to stupid things I did in Util.java, not
> GOST.java. All of which have obviously been corrected now, and in
> correcting I compared my implementation to the specification MANY
> times.
>
> Do note that most implementations of GOST will not generate working
> test vectors for my implementation due to different S-Boxes; they're
> all based on the code in the back of Applied Cryptography (reference
> [1] in GOST.java), which contains different S-Boxes than the ones
> actually specified in Applied Cryptography (which are the ones that
> I've used for my implementaton).

my limited knowledge of GOST 28147-89 is that the (Russian) standard 
does not mandate one S-box; just the algorithm and may be a default 
S-box.  in this case i suggest you re-use, if you are not already doing 
so, one publicly published S-box.  this way this implementation will be 
inter-operable with at least another one.


> I wrote a Mauve test case to make sure things decrypted correctly,
> but Mauve doesn't seem to work for me (every block cipher times out),
> so I just wrote this to test and print stuff:
> http://www.surgo.net/classpath/test.java
>
> I took that specific vector from crypto++ (public domain), but again,
> no idea what the ciphertext there is supposed to mean. It might not
> mean anything: crypto++ has an implementation using four 256-element
> lookup tables instead of S-Boxes; I also didn't see that 11-bit
> left-circular shift at the end, but this could easily be due to the
> tables. So, once again, I'd appreciate it if Casey or Raif or both
> could double-check my implementation.

again, in the absence of standardized test vectors, an inter-operability 
test with another implementation is a must.


> Difficulties found while implementing this:
>
> (1) The number of files you have to modify to add a single block
> cipher, while managable, is excessive. It would be great if we could
> just modify (Registry) and have everything derived from there.
> Failing that, there really needs to be documentation on how to add
> these things -- I just grepped all of classpath for "blowfish" and
> added GOST in everywhere blowfish was.
>
> (2) The file gnu/javax/crypto/jce/cipher/PBES2.java is absolutely out
> of hand. This ties into (1) but is even worse if you want to add a
> new one-way hash function

Re: Using Eclipse on OS X

[Raif S. Naffah]

On Saturday 03 June 2006 06:33, Casey Marshall wrote:
> Hi.
>
> I'm trying to use Eclipse to hack on Classpath on OS X, and have run
> into the immediate problem of `INSTALL' conflicting with `install,'
> since my boot disk is a case-insensitive HFS+ volume (the first is
> the INSTALL file that all GNU packages have; the second is a
> directory (I guess) where the build will install the built
> Classpath). I see that this dir is referenced a bunch of times in the
> *.launch files, which look almost like XML, but not-for-human-eyes
> XML.
>
> Is there some simple setting I can use to change this path?

to use a directory named differently than "install" in Eclipse you have 
to edit the builders' parameters of the project.

* select the project folder from the [Package Explorer] and [Alt-Enter] 
or right-click and select [Properties].

* select [Builders] from the list in the left pane.

* select the following builders: [Configure], [ClasspathHeaders] and 
[ClasspathJar] from the right pane, and in turn, click the [Edit...] 
button.  change the "install" directory name to suit your environment 
anywhere it appears in either the [Working Directory:] and/or 
[Arguments:] fields (under the [Main] tab).


> (I know case-insensitive filesystems are stupid, but that's not what
> I'm asking about)


cheers;
rsn


pgpNYedAKIeJO.pgp
Description: PGP signature

Re: Room for more block ciphers?

[Raif S. Naffah]

hello Morgon,

On Wednesday 31 May 2006 21:59, Morgon Kanter wrote:
> Hello,
>
> Somewhat recently, the gnu-crypto project got merged into Classpath.
> As I live in a cave underground and only come out once every few
> months, I was unaware of this and working on a few new block cipher
> implementations for gnu-crypto, using their old CVS sources.
>
> The old homepage of gnu-crypto said that they were looking for
> someone to add in the NESSIE phase 2 algorithms; this hasn't been
> done yet, from what I see in both the gnu-crypto and classpath CVS.
> I'd be happy to write implementations of these, but the obvious
> question is: would these, and other, new block ciphers even be wanted
> in Classpath? It looks like all of gnu-crypto was merged in, but the
> merge announcement contains the following:
>
> "[W]e would entertain reviving GNU Crypto if someone wanted to
> continue developing it for other purposes (that is, if you have a use
> for GNU Crypto outside of Classpath's more narrow goal of completing
> its JCE providers)"
>
> Which implies that further ciphers wouldn't be wanted or needed for
> Classpath. So, yes, my question is: would new block ciphers be wanted
> in Classpath?

i for one wouldn't be against adding new ciphers, especially the "focus" 
candidates in the eSTREAM project.


cheers;
rsn


pgpFtsqU5WEYW.pgp
Description: PGP signature

Re: Current Release Status for 0.91

[Raif S. Naffah]

hello Andrew,

On Friday 28 April 2006 01:57, Andrew John Hughes wrote:
> On Thu, 27 Apr 2006 16:14:28 +0100
> Andrew John Hughes <[EMAIL PROTECTED]> wrote:
> > On Thu, 27 Apr 2006 16:01:51 +0100
> > Andrew John Hughes <[EMAIL PROTECTED]> wrote:
>...
> Running Mauve against HEAD gave 44279 PASSes and 562 FAILs out of
> 44841 tests. Running Mauve against 0.90 gave 44423 PASSes and 1544
> FAILs out of 45967 tests.
>
> Differences stand at a 120 more FAILs and 797 less PASSes.
>
> The changes from the above seem to be due to time-dependent tests
> like Timers.

for the following tests:

+FAIL: gnu.testlet.gnu.java.security.jce.TestOfDSSKeyPairGenerator 
abnormal termination 142 CRASH or TIMEOUT
+FAIL: gnu.testlet.gnu.java.security.jce.TestOfSignature abnormal 
termination 142 CRASH or TIMEOUT
+FAIL: gnu.testlet.gnu.java.security.jce.TestOfKeyPairGenerator abnormal 
termination 142 CRASH or TIMEOUT
+FAIL: gnu.testlet.gnu.java.security.sig.rsa.TestOfRSAPKCS1V1_5Signature 
abnormal termination 142 CRASH or TIMEOUT

the failures are due to the run-test script timing out and aborting the 
tests.  if you run those tests individually, and wait long enough, they 
should pass.


cheers;
rsn


pgp3NsopE2F3Z.pgp
Description: PGP signature

Re: keytool. was: jarsigner tool

[Raif S. Naffah]

hello Casey,

On Wednesday 29 March 2006 12:01, Casey Marshall wrote:
> On Mar 28, 2006, at 11:56 AM, Raif S. Naffah wrote:
> ...
> Note that there is a beginning of a keytool implementation in GNU
> Crypto CVS. Some of the basic functions work (list, export, and
> import, I think), so it may be helpful to start with that code
> instead of from scratch.

thanks.  i'll see what i can borrow from there.


cheers;
rsn


pgpiSdWOiLwgs.pgp
Description: PGP signature

keytool. was: jarsigner tool

[Raif S. Naffah]

hello Mark,

On Wednesday 29 March 2006 03:45, Mark Wielaard wrote:
> ...
> > I will send an email to FSF legal about using a (reimplementation)
> > of the JKS format.
>
> Done and answered. We are free to reimplement this. File formats and
> algorithms aren't copyrightable, so any code we write to conform to
> the description given (see below) is OK. Now all we need is someone
> willing to actually implement this and add it as a standard KeyStore
> format we support.

this is great news!

until a volunteer raises his/her hand and contribute the implementation, 
i'll start working on the keytool tool.


cheers;
rsn


pgpEjZwKoJ3Pq.pgp
Description: PGP signature

Re: jarsigner tool

[Raif S. Naffah]

hello Roman,

On Thursday 23 March 2006 23:18, Roman Kennke wrote:
> ...A jarsigner can well be
> implemented without JKS and have a Provider plugged in for different
> keystore formats. This would be done via the
> java.security.KeyStore.getInstance() method AFAICS. I think this is
> what Sun's jarsigner also does via the --provider and/or --storetype
> arguments. So my opinion is that we should have a jarsignder
> implementation that uses this API and the same options but a
> different default

my implementation does that.


cheers;
rsn


pgpYR2fKcofKj.pgp
Description: PGP signature

Re: jarsigner tool

[Raif S. Naffah]

hello Mark,

On Thursday 23 March 2006 22:06, Mark Wielaard wrote:
> On Thu, 2006-03-23 at 21:16 +1100, Raif S. Naffah wrote:
> ...i'd like a second opinion on a legal-related issue.
> >
> > the tool reads and uses private and public cryptographic data from
> > a keystore that is in a proprietary format: "JKS" from Sun.  the
> > code i use to do the reading from such a keystore* is available at
> > <http://metastatic.org/source/JKS.java>.
> >
> > i'd like a ruling on whether it's ok to import and use this code in
> > GNU Classpath.
>
> Unfortunately no. The last time this came up FSF legal didn't like us
> using code which was written by reverse engineering the original code
> and format. And for which no public documentation was available at
> all. We can ask again of course. And maybe just using the description
> of the format (which I believe is also documented outside the code
> you reference itself) and then letting someone else write a new
> implementation for it is OK.
>
> The question is also whether we really need to support this
> undocumented keystore format. There are open formats. And we can also
> work towards something like
> http://metastatic.org/text/gnu-keyring.txt
>
> What is your opinion? Is it important enough to support this JKS
> format to try and jump through some legal hoops? Or can we just stick
> to open keystore formats?

i think yes for two reasons:

1. for everything Java, Sun sets the pace.  in practice if Sun offers a 
format, an API, etc... Java programmers will use it in preference to 
any other alternative.  an example would be the log4j logging API v/s 
jdk logging.

2. if the alternative is not a drop-in replacement, there will always be 
a reticence, by Java programmers, to that alternative compared to what 
Sun offers.  an example is our endeavor (GNU Classpath), to match the 
behavior of Sun's JDKs, incl. bugs!


cheers;
rsn


pgpLSm0rPacPC.pgp
Description: PGP signature

jarsigner tool

[Raif S. Naffah]

hello all,

i now have a working first (rough) cut of the above.  but before i check 
the code in i'd like a second opinion on a legal-related issue.

the tool reads and uses private and public cryptographic data from a 
keystore that is in a proprietary format: "JKS" from Sun.  the code i 
use to do the reading from such a keystore* is available at 
.

i'd like a ruling on whether it's ok to import and use this code in GNU 
Classpath.


* the keystore i used for testing was generated by Sun's JDK 1.4.2_11 
keytool.


TIA + cheers;
rsn


pgp18apu4vSqK.pgp
Description: PGP signature

RFI: Manifest line endings is platform independant

[Raif S. Naffah]

hello there,

while working on the jarsigner tool, i am seeing the Manifest file being 
generated by both JDKs 1.4 and 1.5, is using a 0x0D0A as its line 
endings, even when the jar file containing this manifest was generated 
on a linux platform.  this is not the case with our implementation of 
the JarOutputStream which uses the platform-specific line endings.

can somebody confirm this is the case on other platforms as well.


TIA + cheers;
rsn


pgprgeUHDBipr.pgp
Description: PGP signature

Re: milestone for release 1. was Next release

[Raif S. Naffah]

hello Mark,

On Wednesday 01 March 2006 22:23, Mark Wielaard wrote:
> On Wed, 2006-03-01 at 05:51 +1100, Raif S. Naffah wrote:
> > what is the expected milestone (definition and how to measure it)
> > to reach before releasing a version 1 --or 1.4 whatever that final
> > number will be?
>
> According to our homepage it is: "GNU Classpath 1.0 will be fully
> compatible with the 1.1 and largely compliant with the 1.2 API
> specification and will have a stable API for interacting with virtual
> machines." Which I think we have now (plus lots of additional 1.3,
> 1.4 and 1.5 stuff).

i was, and still am interested, in getting a common consensus on what 
would constitute a "non 0. release"!


> Personally I think 1.0 is when we feel it isn't just some
> experimental code anymore, but that people can use GNU Classpath for
> real world applications, and we feel comfortable supporting those
> users. Which also has been true (for years). Just look at any recent
> distribution...

i would like to see a more quantifiable description of when we can say 
we reached that 1.0 release level.  measuring a difference against the 
API of the JDK 1.4 is not enough, IMHO, as a target milestone.

i do agree with you that applications, and i would add tools, would be a 
better measure of our readiness for a 1.0 release.  having a specific 
list of (JDK) tools we must have, and applications that must run with 
no errors or problems, will determine:

a. the API implementations we have to have --does not matter then how 
close or far we are from the 100% API match.

b. the bugs we have to squash, and

c. the Mauve tests we have to monitor to ensure no regressions are 
introduced.

and consequently if we have a 1.0 release, or how far we are from having 
one.


cheers;
rsn


pgpRYBMBiT47V.pgp
Description: PGP signature

milestone for release 1. was Next release

[Raif S. Naffah]

hello all,

what is the expected milestone (definition and how to measure it) to 
reach before releasing a version 1 --or 1.4 whatever that final number 
will be?


cheers;
rsn


pgpedKocpYsKX.pgp
Description: PGP signature

Re: implementing javax.security.auth.kerberos

[Raif S. Naffah]

hello all,

On Tuesday 28 February 2006 07:14, Mark Wielaard wrote:
> On Tue, 2006-02-28 at 07:04 +1100, Raif S. Naffah wrote:
> > if anyone is already working on them let me know, otherwise i'll
> > start implementing these missing classes.
>
> Jeff started on this. See:
> http://lists.gnu.org/archive/html/classpath/2005-11/msg00150.html
> Please coordinate with him.

and later On Tuesday 28 February 2006 07:21, Casey Marshall wrote:
> ...
> There was a patch to provide KerberosPrincipal:
>
>http://lists.gnu.org/archive/html/classpath-patches/2005-11/
> msg00408.html
>
> And there were some threads on providing a Kerberos implementation
> backing these up, either through a Java implementation, or by hooking
> into a free C version.

as long as Jeff's working on it that's fine.  

Jeff, if you need a hand let me know, in the meantime i'll get busy 
fixing the HTTPS stuff.


cheers;
rsn


pgpcahKC4sL3z.pgp
Description: PGP signature

implementing javax.security.auth.kerberos

[Raif S. Naffah]

hello all,

looking at the latest JAPI comparisons with JDK 1.4, i noticed we're 
missing the above.

if anyone is already working on them let me know, otherwise i'll start 
implementing these missing classes.


cheers;
rsn


pgp7xVamJfHyi.pgp
Description: PGP signature

Re: RFC: jessie-nio branch, keytool

[Raif S. Naffah]

hello Casey,

On Monday 27 February 2006 08:42, Casey Marshall wrote:
> ...
> Also, in GNU Crypto we were working on a replacement for `keytool;'
> do we want to merge that into Classpath, too?

i personally think it should be added to the gnu.classpath.tools.

there are also two other tools that come with the JDK, which i don't
think we are providing in Classpath:

* jarsigner, and
* policytool.

i can work on the first of these two, if there isn't already a free
implementation we can [re-]use.


cheers;
rsn


pgp0AIwq83Ws5.pgp
Description: PGP signature

Re: gnu classpath and crypto SealedObject usage

[Raif S. Naffah]

On Thursday 26 January 2006 23:15, [EMAIL PROTECTED] wrote:
> Raif S. Naffah wrote:
> > hello tabun,
> >
> > On Thursday 26 January 2006 16:59, [EMAIL PROTECTED] wrote:
> >>Hi there,
> >>
> >>I'm attempting to use a SealedObject with gcj
> >
> > please post a minimal code that causes the exception to occur.
> >
> >
> > TIA + cheers;
> > rsn
>
> Ok, I recoded it into two different functions...

PR created (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25981) and the 
fix will be checked-in shortly --it will be included in the next 
release of Classpath.


thanks for your report + cheers;
rsn


pgpapF68uZI2u.pgp
Description: PGP signature

Re: gnu classpath and crypto SealedObject usage

[Raif S. Naffah]

hello tabun,

On Thursday 26 January 2006 16:59, [EMAIL PROTECTED] wrote:
> Hi there,
>
> I'm attempting to use a SealedObject with gcj

please post a minimal code that causes the exception to occur.


TIA + cheers;
rsn


pgpr1szE5CGBw.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://developer.classpath.org/mailman/listinfo/classpath

[The Book]

[Raif S. Naffah]

On Sunday 15 January 2006 07:51, i wrote:
> ...
> Classpath is more than just a bunch of APIs, and if there's a book
> worth reading about Java (and free VMs) it would be about what this
> project, its team of collaborators and hackers, and user VMs.  i'm
> not talking about people but software: what more, or better,
> Classpath + friends offer to the Java developers.
>
> has anybody given a thought to the idea of publishing such a book?

the responses are encouraging :-)

i suggest we move to the next stage: working out an Outline, before 
finding a Publisher.  i am guessing having an Outline may be (i am 
guessing here) a requisite to finding the Publisher --leaving Lulu as a 
last resort.

unless somebody else beats me to it, i'll post a proposal for an Outline 
soon, and will keep up-to-date a Wiki page ("TheBook") for the contents 
of that Outline.

if there are no objections, we can continue using this list as the 
vehicle for discussions.  to make it easier for those not interested to 
filter out emails related to this project, we can use [The Book] at the 
beginning of the subject line.


cheers;
rsn


pgpSlgOtEdVBA.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [Bug classpath/25202] javax.security.auth.login.LoginException: no configured modules for

[Raif S. Naffah]

On Sunday 15 January 2006 14:15, Casey Marshall wrote:
> ...
> In the case of JAAS, to call e.g. `Configuration.refresh', you need
> the permission:
>
>javax.security.auth.AuthPermission ("refreshLoginConfiguration");
>
> ...and nothing else. Presumably this means you can call that method
> even if you don't have any `PropertyPermissions' granted to you.

one would call a refresh() after they successfully setup (and read a 
config file).  if they can not setup a config file (by creating a 
LoginContext), they should not get a different result when they do a  
refresh().

besides, which is more important, these are permissions for the 
_implementors_ of Configuration not its users.  so if there are 
permissions to be bypassed (and i am not implying we should) it would 
be those not the others.


> IOW, 
> it doesn't make sense if GnuConfiguration.refresh throws a
> SecurityException if the caller has `AuthPermission
> ("refreshLoginConfiguration")' but doesn't have, say,
> `SecurityPermission
> ("getProperty.java.security.auth.login.config.url.N").' That this
> implementation requires other permissions to do its job isn't
> relevant.

see later.


> (I looked over the patch again, and see that you'll only throw a
> SecurityException in `processSecurityProperties.' The other methods
> just fail silently (except for debug output) which I think is the
> wrong thing to do.)

i changed it to be similar to the other lookup methods; i.e. catch all 
the exceptions and continue looking in other places.


let's recap here the two approaches:

* in the proposed patch, for a user to be able to setup their own login 
config modules they need:

A. at least one of the followings:

  1. permission java.lang.SecurityPermission
   "getProperty.java.security.auth.login.config.url.1",
   "read";
  2. permission java.util.PropertyPermission
   "java.security.auth.login.config",
   "read";
  3. permission java.io.FilePermission
   "${user.home}/.java.login.config",
   "read";

B. in addition, if either A.1 or A.2 are allowed, and assuming they 
reference files on "my.host.name" at port 80, or files on the local 
machine (/var/data/ for example), one of the following additional 
permissions are required:

  1. permission java.netSocketPermission
"my.host.name:80",
"connect,accept,listen";
  2. permission java.io.FilePermission
"/var/data/-",
"read";

* what you're saying is let's bypass the security manager checks for A.2 
but leave the rest.  is this an accurate assessment?


cheers;
rsn


pgpOoyKebxk2S.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [Bug classpath/25202] javax.security.auth.login.LoginException: no configured modules for

[Raif S. Naffah]

On Sunday 15 January 2006 12:23, Casey Marshall wrote:
> On Jan 14, 2006, at 4:56 PM, raif at swiftdsl dot com dot au wrote:
> > On Sunday 15 January 2006 11:21, csm at gnu dot org wrote:
> >> On Jan 14, 2006, at 3:02 PM, raif at swiftdsl dot com dot au wrote:
> >>> On Sunday 15 January 2006 09:29, csm at gnu dot org wrote:
>  That is, code should be permitted to use JAAS, but NOT permitted
>  to read anything sensitive at the same time.
> >>>
> >>> the use of the Configuration (and its subclasses) is itself
> >>> conditioned
> >>> by security properties; e.g. the refresh() method.  why then
> >>> would you want to respect that restriction on the Configuration
> >>> itself but bypass
> >>> it in its implementation?
> >>
> >> Those are (I believe) separate permissions; as a user of JAAS, I'd
> >> expect if I'm granted permission to use JAAS, then I should be
> >> able to use it, whether or not that means the *implementation* of
> >> JAAS does something else that requires permission.
> >>
> >> I mean, why should a programmer using the JAAS API have to care
> >> about what goes on behind the scenes?
> >
> > let's consider this scenario:
> >
> > 1. GnuConfiguration bypasses security checks and reads system
> > property.
> > 2. rogue user A usually has no login access to application ACME,
> > and does not have permission to read/write the jass config system
> > related properties.
> > 3. A writes a phony login module and specifies it in a config file
> > at location L.
> > 4. A then calls java -Djava.security.auth.login.config=L ...
> >
> > A now can login into previously unauthorized ACME!
>
> I think that argument is a little specious. The `java -D...' feature
> is a part of a command-line interface to a Java runtime...

i used java -D in the scenario above but feel free to replace it with 
System.setProperty(...).  now the latter is not restricted as the 
former.


> I also don't exactly see why the scenario you suggest is exploitable
> if PropertyPermissions are bypassed internally, but not exploitable
> otherwise. Someone can call `java -
> Djava.security.auth.login.config=L' regardless, right? If some
> application depending on JAAS is vulnerable to that, it's generally
> vulnerable.

because in a coherent situation if i don't want to allow A setting their 
own login config files and classes, and hence indirectly bypassing / 
replacing my authorization (login modules), i would not grant A 
read/write permissions to the jaas-related properties.


> >>> this only addresses system properties, what about the security
> >>> properties and file reading?  are you implying running (all) the
> >>> Configuration logic as privileged code?
> >>
> >> Obviously not, but running the parts that require permission --
> >> which the caller may not have or need -- should be...
> >
> > like the scenario above shows.  doing it the way you propose may
> > lead to undesirable effects.
>
> I still don't get it. Say we have the method `Foo.doFrob(),' which
> requires that the caller have `FrobPermission.' It doesn't require
> any other permissions. If our *implementation* of `doFrob' needs to
> read a system property, it needs `PropertyPermission' for that, but
> the caller of `doFrob' doesn't, so the implementation of `doFrob'
> must run that part of the code as privileged.

... or in the security policy file, grant the caller read/write 
permissions to the doFrob property permission; e.g.

grant codeBase "file:myDoFrobImpl.jar" {
  permission java.util.PropertyPermission "doFrob", "read";
  ...
};

grant codeBase "file:yourDoFrobImpl.jar" {
//  no doFrob for you
//  permission java.util.PropertyPermission "doFrob", "read";
...
};


cheers;
rsn


pgpESBdvrmANC.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

a crazy idea -- the Book

[Raif S. Naffah]

hello all,

with every visit to the bookstore i see new titles about java, swing, 
etc.  most of them being just printed collections of already public 
APIs.

Classpath is more than just a bunch of APIs, and if there's a book worth 
reading about Java (and free VMs) it would be about what this project, 
its team of collaborators and hackers, and user VMs.  i'm not talking 
about people but software: what more, or better, Classpath + friends 
offer to the Java developers.

has anybody given a thought to the idea of publishing such a book?


cheers;
rsn


pgpLRJEECjjEM.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Using a workspace-based VM in Eclipse

[Raif S. Naffah]

On Saturday 07 January 2006 01:55, Tom Tromey wrote:
> > "Anthony" == Anthony Green <[EMAIL PROTECTED]> writes:
>
> Anthony> This worked pretty well for me, thanks.  I wasn't able to
> get Anthony> cacao via cvs (server down?), so I used jamvm.  The only
> Anthony> gotcha I had is that jamvm requires jikes to build, which I
> Anthony> did't have installed.  Manually changing the Makefile jikes
> Anthony> reference to ecj worked.
>
> I just did 'yum install jikes'.  We ought to fix this though.

doesn't cacao also use jikes? (ref. 
${CACAO_HOME}/src/lib/vm/reference/Makefile.am)


cheers;
rsn


pgpGhNIbTWPFq.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: JUnit

[Raif S. Naffah]

hello Tom,

On Wednesday 28 December 2005 12:01, Tom Tromey wrote:
> >>>>> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
> >>
> >> I think we ought to change Mauve to use JUnit as well...
>
> Raif> do you see this as a new module under the Mauve CVS, say
> "junit" or a Raif> folder-hierarchy under the current "mauve" module?
>
> I mean simply converting the whole mauve to use junit, preferably all
> at once.  So, no new directory at all.

this sounds like a mammoth task.  wouldn't allowing for a transition 
period where the two frameworks --(Mauve) Testlet and (JUnit) 
TestCase)-- co-exist has better chances of enlisting contributors?


on a related note, and as an exercise, i tried adapting the TestHarness 
and SingleTestHarness to allow running a Testlet as a JUnit TestCase.  
this worked but unfortunately, due to the clash between the "fail()" 
instance method in Testlet and the same static method in TestCase i was 
unable to have both at the same time; i.e. Testlet being run as Mauve 
as well as JUnit.  at the end i was not too sure about the value of 
achieving this simultaneity.


also, with Mauve we have an easy way for "selecting" the tests --the 
"tagging" feature-- do you see dropping this and using instead 
hand-crafted TestSuites?


finally, if the decision to move away from Mauve exists, is it worth our 
while looking at other frameworks such as TestNG (see 
http://testng.org/doc/)?


cheers;
rsn


pgp31DN08eS8k.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: New GNU Classpath developer Raif Naffah

[Raif S. Naffah]

hello Mark and Audrius,

On Tuesday 03 January 2006 07:23, Mark Wielaard wrote:
> ...
> I am happy to announce that Raïf decided to become one of our active
> hackers...
> ...
> ...Please post a patch and
> ChangeLog entry to add yourself to the AUTHORS file to the
> classpath-patches mailinglist. You can consider that patch
> pre-approved so feel free to commit it immediately as a test of your
> new powers. But remember that with power comes responsibility! (*)

noted.  i'll try to earn my keep :-)


On Tuesday 03 January 2006 19:00, Meskauskas Audrius wrote:
> Congratulations, Raif, nice to meet  you!

thanks Audrius :-)

-- 
cheers;
rsn


pgpwAjZtPvsl6.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [GNU Crypto] Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie

[Raif S. Naffah]

hello Anthony,

On Monday 12 December 2005 20:52, Anthony Green wrote:
> On Mon, 2005-12-12 at 20:48 +1100, Raif S. Naffah wrote:
> > would adding a second Provider --that supplies the strong stuff;
> > i.e. ciphers, modes, padding, etc..-- living in its own package
> > sub-directory/hierarchy and eventually (when the segmentation of
> > Classpath into multiple jars occur) be packaged in its own jar help
> > solve your problem?
>
> Yes, that would be nice.

looking at the current Classpath package structure and classes, i see 
that an implementation of a Cipher using RSA is already included.  
those are normally part of the javax.crypto strain.  do you strip those 
out when you package your export-controlled applications?


cheers;
rsn


pgpBcUaqmp7QO.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

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


pgp2uxCEdYYl2.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: JUnit

[Raif S. Naffah]

On Saturday 24 December 2005 09:15, Tom Tromey wrote:
> >>>>> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
>
> Raif> the proposal is to port the GNU Crypto Mauve tests to use JUnit
> Raif> instead.  this would make it easier to test using an IDE such
> as Raif> the Native Eclipse.
>
> Raif> is this idea worth discussing or should we consider that for
> the Raif> forseeable future Mauve only is the test framework for GNU
> Classpath?
>
> I think we ought to change Mauve to use JUnit as well...

do you see this as a new module under the Mauve CVS, say "junit" or a 
folder-hierarchy under the current "mauve" module?


cheers;
rsn


pgpve1Moe2Ire.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

JUnit

[Raif S. Naffah]

hello all,

soon the GNU Crypto classes will be moving to Classpath.  i thought now 
is the right time to bring this subject since it makes it easier for 
those involved in this work.

the proposal is to port the GNU Crypto Mauve tests to use JUnit instead.  
this would make it easier to test using an IDE such as the Native 
Eclipse.

is this idea worth discussing or should we consider that for the 
forseeable future Mauve only is the test framework for GNU Classpath?


cheers;
rsn


pgpabdpcFXQDl.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Using a workspace-based VM in Eclipse

[Raif S. Naffah]

hello Mark,

On Friday 23 December 2005 21:56, Mark Wielaard wrote:
> On Fri, 2005-12-23 at 19:56 +1100, Raif S. Naffah wrote:
> > > Now, go to Window->Preferences->Java->Installed JREs and choose
> > > 'Add...' to add a new one.  I named mine "Cacao".  For the JRE
> > > home directory, choose $workspace/fakejdk.  Then turn off "Use
> > > default system libraries" and you can edit the Source attachment
> > > of the new JRE to point to the classpath directory in the
> > > workspace.
> >
> > when i do that Eclipse claims that "Target is not a JDK root.
> > System library was not found."
> >
> > this turns out to be caused by the fact that the instructions to
> > follow do not cause a glibj.zip to be generated, and hence be used
> > as the fake rt.jar.
>
> Are you sure you have the latest GNU Classpath CVS checked out in
> eclipse? Tom added a new Builder ClasspathJar that generates a
> glibj.zip after everything else has been build. See classpath Project
> -> Properties -> Builders.

looks like i didn't when i tried it earlier.  works like a charm.

thanks + cheers;
rsn


pgpvyl84aVnt2.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Using a workspace-based VM in Eclipse

[Raif S. Naffah]

On Friday 23 December 2005 06:34, Tom Tromey wrote:
> I've checked in the Eclipse jar builder to Classpath head, and now my
> fakejdk project is available.  This means you can easily start
> playing with an in-workspace VM in Eclipse.
>
> To do this, follow the wiki instructions to check out and build
> Classpath and Cacao (as always, this VM is chosen because all the
> needed build bits are in its cvs repository... hint to the other VM
> developers).
>
> Once that is done, check out the fakejdk project from
>
> :pserver:[EMAIL PROTECTED]:/cvs/rhug, module 'fakejdk'.
>
> (This ought to auto-build, but if not, apply the usual Clean hack.)
> This just makes a little project consisting of symlinks -- it is a
> huge hack.
>
> Now, go to Window->Preferences->Java->Installed JREs and choose
> 'Add...' to add a new one.  I named mine "Cacao".  For the JRE home
> directory, choose $workspace/fakejdk.  Then turn off "Use default
> system libraries" and you can edit the Source attachment of the new
> JRE to point to the classpath directory in the workspace.

when i do that Eclipse claims that "Target is not a JDK root. System 
library was not found."

this turns out to be caused by the fact that the instructions to follow 
do not cause a glibj.zip to be generated, and hence be used as the fake 
rt.jar.


> Once this is done you can pick this JRE for launchers, or to build
> other projects against.  This is nice because it means these projects
> don't have to necessarily depend on Classpath -- there is a layer of
> indirection, so you can build and run them against the system VM if
> you prefer to do that, without modifying the shared build setup.
>
> Tom


cheers;
rsn


pgp0qXtfQwHMf.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [GNU Crypto] Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie

[Raif S. Naffah]

On Monday 12 December 2005 01:45, Anthony Green wrote:
> On Sun, 2005-12-11 at 15:19 +0100, Mark Wielaard wrote:
> > If there are situations where you are not able to (re)distribute
> > the GNU Classpath source code and/or follow the the BIS/ENC
> > notification procedures as done by the various GNU/Linux distros to
> > distribute binary derivatives of GNU Classpath as Free Software
> > works then please let us know.
>
> I don't think my situation is relevant to public Linux distros.
>
> I'm told the rules are different when you want to make a private
> distribution of FOSS crypto code (ie. not easily found on a public
> web/ftp site).  In my specific case, it's easier just to remove the
> problematic code completely.

would adding a second Provider --that supplies the strong stuff; i.e. 
ciphers, modes, padding, etc..-- living in its own package 
sub-directory/hierarchy and eventually (when the segmentation of 
Classpath into multiple jars occur) be packaged in its own jar help 
solve your problem?


cheers;
rsn


pgpwTIeTvE2l2.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie

[Raif S. Naffah]

On Thursday 08 December 2005 08:21, Casey Marshall wrote:
> On Dec 6, 2005, at 11:57 PM, Raif S. Naffah wrote:
> > On Wednesday 07 December 2005 04:49, Casey Marshall wrote:
> >> On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote:
> >>> On Tuesday 06 December 2005 18:42, Casey Marshall wrote:
> >>>> A few of us have been throwing around the idea of merging GNU
> >>>> Crypto and Jessie into GNU Classpath, so Classpath will have
> >>>> full support for crypto and SSL "out of the box." We've proposed
> >>>> this before, and I think this idea was mostly approved by the
> >>>> group, but no-one ever got around to doing it.
> >>>>
> >>>> I'd like to propose again that we do this. I'll try to get to
> >>>> this myself, but if I can't get this done, we'll at least have a
> >>>> plan of action. I propose that we
> >>>>
> >>>>- Rename the root package 'gnu.crypto' to 'gnu.javax.crypto'
> >>>> in GNU Crypto, and merge the current CVS sources into Classpath
> >>>> (not under external/). We then put GNU Crypto into a kind of
> >>>> "stasis" mode, and continue to develop these sources in
> >>>> Classpath. - Rename the root package 'org.metastatic.jessie' to
> >>>> 'gnu.javax.net.ssl' in Jessie, and merge the current sources.
> >>>> Then, I'll stop developing that branch on its own.
> >>>
> >>> does this mean that Classpath's crypto classes will be using the
> >>> GNU Crypto "assembly, cipher, hash, key, mac, mode, pad, prng and
  
> >>> "sig" sub-packages with the "jce" wrappers?
> >>
> >> Basically yes. The goal is to merge "everything with a JCE
> >> wrapper," because that will fill in many algorithms present in
> >> proprietary VMs, but currently missing in Classpath.
> >
> > cool.  i can help with this task  --can spend ~2hrs/day on this
> > until it's done.
>
> Great! School's out for me right now, so I have my weekends back :-)
>
> >> Things without JCE wrappers don't really make sense for Classpath,
> >> because they aren't portably accessible.
> >
> > dont know exactly what you mean by this but i'll have a closer look
> > at the Classpath classes; it may become evident then.
>
> By this I mean that if something can't be used through J2SE classes,
> then it probably shouldn't be merged, because otherwise we'd be
> introducing private, non-portable APIs into Classpath. Exceptions are
> things we know we'll need to use privately (e.g., if Jessie needs
> it).
>
> The assembly package is a good example: it's a neat, advanced API,
> but doesn't have any analogue in the J2SE spec.

ahhh... i was afraid of that, that's why i asked about it earlier and i 
was led to believe it will be part of Classpath.

i still haven't had the time to study closely the security classes in 
Classpath, but consider the following:

* the GNU Provider can implement the triplet cipher/mode/pad using the 
Assembly classes.

* the gnu.* subpackages that provide the implementation for the GNU 
Provider, if/when Classpath's single jar is broken into multiple jars, 
can then be (jarred as one of Classpath's jars, and) used by others 
wishing to use an API other than the JCA.

how does that sound?


> Thanks.


cheers;
rsn


pgpgvHsihMVJL.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie

[Raif S. Naffah]

On Wednesday 07 December 2005 04:49, Casey Marshall wrote:
> On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote:
> > On Tuesday 06 December 2005 18:42, Casey Marshall wrote:
> >> A few of us have been throwing around the idea of merging GNU
> >> Crypto and Jessie into GNU Classpath, so Classpath will have full
> >> support for crypto and SSL "out of the box." We've proposed this
> >> before, and I think this idea was mostly approved by the group,
> >> but no-one ever got around to doing it.
> >>
> >> I'd like to propose again that we do this. I'll try to get to this
> >> myself, but if I can't get this done, we'll at least have a plan
> >> of action. I propose that we
> >>
> >>- Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in
> >> GNU Crypto, and merge the current CVS sources into Classpath (not
> >> under external/). We then put GNU Crypto into a kind of "stasis"
> >> mode, and continue to develop these sources in Classpath.
> >>- Rename the root package 'org.metastatic.jessie' to
> >> 'gnu.javax.net.ssl' in Jessie, and merge the current sources.
> >> Then, I'll stop developing that branch on its own.
> >
> > does this mean that Classpath's crypto classes will be using the
> > GNU Crypto "assembly, cipher, hash, key, mac, mode, pad, prng and
> > "sig" sub-packages with the "jce" wrappers?
>
> Basically yes. The goal is to merge "everything with a JCE wrapper,"
> because that will fill in many algorithms present in proprietary VMs,
> but currently missing in Classpath.

cool.  i can help with this task  --can spend ~2hrs/day on this until 
it's done.


> Things without JCE wrappers don't really make sense for Classpath,
> because they aren't portably accessible.

dont know exactly what you mean by this but i'll have a closer look at 
the Classpath classes; it may become evident then.


> Thanks.


cheers;
rsn


pgpUyEMU00Zgc.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie

[Raif S. Naffah]

On Tuesday 06 December 2005 18:42, Casey Marshall wrote:
> A few of us have been throwing around the idea of merging GNU Crypto
> and Jessie into GNU Classpath, so Classpath will have full support
> for crypto and SSL "out of the box." We've proposed this before, and
> I think this idea was mostly approved by the group, but no-one ever
> got around to doing it.
>
> I'd like to propose again that we do this. I'll try to get to this
> myself, but if I can't get this done, we'll at least have a plan of
> action. I propose that we
>
>- Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in
> GNU Crypto, and merge the current CVS sources into Classpath (not
> under external/). We then put GNU Crypto into a kind of "stasis"
> mode, and continue to develop these sources in Classpath.
>- Rename the root package 'org.metastatic.jessie' to
> 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then,
> I'll stop developing that branch on its own.

does this mean that Classpath's crypto classes will be using the GNU 
Crypto "assembly, cipher, hash, key, mac, mode, pad, prng and "sig" 
sub-packages with the "jce" wrappers?


> We can then also merge other parts of GNU Crypto to projects where
> they make sense; its testsuite can go into Mauve (it was written to
> use (a possibly old version of) Mauve's own test harness classes),
> and the various tools can go into cp-tools.
>
> I think most Classpath hackers think this is a good idea; I'm sending
> this mail out to the individual project lists to see if there are any
> objections from users of either package. To be clear, GNU Crypto
> won't go away, while Jessie will. GNU Crypto MAY continue to be
> developed, but not by me (and if history is a precedent, then neither
> by anyone else).
>
> If I'm not able to put this patch together, I will answer anyone's
> questions about how to proceed, if we get a volunteer.
>
> Thanks.


cheers;
rsn


pgpF6H2c1pVQe.pgp
Description: PGP signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Merging crypto into classpath

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello Casey,

On Mon, 19 Jul 2004 05:40, Casey Marshall wrote:
> >>>>> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
>
> Raif> On Mon, 19 Jul 2004 05:09, Casey Marshall wrote:
> >> We've recently gotten an OK to merge the parts of the Java class
> >> library implemented by GNU Crypto [1] and Jessie [2] into GNU
> >> Classpath...
>
> Raif> any reason why javax.security.sasl.* classes are not included
> in Raif> this merge?
>
> That package isn't a part of any "stable" version of the API,
> correct? Will that be a part of Java 1.5/5.0/whatever?

it is part of the 1.5 release --see 
http://java.sun.com/j2se/1.5.0/docs/api/javax/security/sasl/package-summary.html.  
this being the realisation of JSR-28: see 
http://jcp.org/en/jsr/detail?id=28


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Que du magnifique

iD8DBQFA+tlB+e1AKnsTRiERA7OdAJ0eO5YRRrTzOdn0LW3zZpic5Zfu3ACfRjrB
P+sl4xY+olAIVg2yvwam8Bc=
=CX9v
-END PGP SIGNATURE-


___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: Merging crypto into classpath

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello Casey,

On Mon, 19 Jul 2004 05:09, Casey Marshall wrote:
> We've recently gotten an OK to merge the parts of the Java class
> library implemented by GNU Crypto [1] and Jessie [2] into GNU
> Classpath...

any reason why javax.security.sasl.* classes are not included in this 
merge?


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Que du magnifique

iD8DBQFA+s2G+e1AKnsTRiERAymIAKDlE3Ih5SgCK1xr1RwaOY6ZG3wWPgCg2RsY
G1b+oVUXpcw5ojjK5Lat7YE=
=OzOm
-END PGP SIGNATURE-


___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath

Re: [GNU Crypto] Re: gnu-crypto.m4. was: new jalopy available

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello Dalibor,

On Mon, 24 Nov 2003 05:16 am, Dalibor Topic wrote:
> Raif S. Naffah wrote:
> > On Sat, 22 Nov 2003 10:51 am, Dalibor Topic wrote:
> >>...
> >>p.s. is there some kind of gnu-crypto.m4 file for automake to add a
> >>--with-gnu-crypto option to it? I'd love having a simple way to
> >> chuck in GNU crypto into kaffe without having to bother with those
> >> weird U.S. crypto laws, as kaffe's CVS server is located in
> >> California.
> > ...
> > things to consider are:
> >
> > * building gnu crypto is effectively building three jars/libraries:
> > one is the gnu-crypto per se (incl. the JCE Adapters), the other
> > two are javax-crypto and javax-security (callbacks and sasl).
>
> So we have three seperate jar files, right?

correct.


>... Then we need a way to put
> those in the bootclasspath of the calling VM.

i need to double check this but from memory you only need the 
javax-crypto.jar only on the bootclasspath iff kaffe exhibits the same 
behaviour as the jdk1.4; otherwise it only need to be accessible from 
the classpath (similar to any other jar).


>... The VM will need to
> figure out the location of the jar files to add to it's
> bootclasspath.
>
> Let's say we have
>
> --with-gnu-crypto[=PATH-TO-JAR-LOCATION]
>
> as an API.

yes.  if the optional PATH-TO-JAR-LOCATION is omitted, then [the | a] 
default list of destinations would be searched, incl. 
/usr/local/gnu-crypto.  (see the _GNU_CRYPTO_WITH_CLASSPATH macro 
(lines 119+ in  
<http://savannah.gnu.org/cgi-bin/viewcvs/gnu-crypto/gnu-crypto/acinclude.m4?rev=1.11&content-type=text/vnd.viewcvs-markup>).
  
otherwise the designated path, and only that path, is considered.

if/when the expected jars are found in the location, the macro:

a. prints a message that it found, or not, the expected jars;
b. sets, as you suggest later the two ac variables:

   USE_GNU_CRYPTO, and
   GNU_CRYPTO_HOME (or similar).


> Maybe even a
> --with-gnu-crypto-cvs=PATH-TO-GNU-CRYPTO-CVS-CHECKOUT

i'm doubtful of the value of this since we (GNU Crypto) always build 
outside the CVS directory.  but you may have some ideas that would work 
around this situation.  if not i'd leave this "feature" to a followup 
release :-)


> API later for those among us who like building from CVS checkouts ;)
>
> So basically, I'm thinking about two APIs (macros), one for JARs, and
> another for rebuilding GNU Crpyto from CVS. I'll concentrate in the
> first, as that one seems to be easier to do as a prototype, and with
> lessons from that one, it should be easier to build the other.

agree.


> > * once installed in a location (default is /usr/local/gnu-crypto)
> > it should be straightforward to construct the different
> > options/switches needed by the kaffe build script from the contents
> > of that location.
>
> I have the following in mind:
>
> --with-gnu-crypto should set USE_GNU_CRYPTO as an autoconf variable,
> and PATH_TO_GNU_CRYPTO_JARS. Then, we can use one to check if kaffe
> should use GNU crypto, and the other to adapth the bootclasspath in
> the kaffe driver script, kaffe.in.

agree.


> > * it would be nice to be able to re-use most, if not all, of the
> > generated options/switches of such an m4 library with other VM
> > providers; e.g. kissme and jikes rvm.
>
> The options/switches depend on the options/switches from the GNU
> crypto configure.in you want the projects utilising GNU Crypto to be
> able to change. If there are any of them that make sense once you've
> uild the JAR files, we should list a set of
> --enable-gnu-crypto-something switches to allow the VM to enable
> those features.

again, the fact that we build outside the CVS directory, IMO makes it 
hard to chain build GNU Crypto with other projects.

on the other hand, i think what we have discussed so far would allow 
easy integration of GNU Crypto jars with every VM provider; i.e. once 
GNU_CRYPTO_HOME is set, and depending on the requirements of the 
specific VM, the appropriate jars can be constructed as part of the 
bootclasspath (or equivalent) and/or the plain classpath.


> > if you think this is worth it, let's continue this thread on the
> > GNU Crypto list.
>
> I've cc:ed the kaffe mailing list, as I assume kaffe will provide the
> testbed for this type of integration.

much appreciated :-)  i'll delay the release until we have this working.


> > p.s. if there is a Debian packager out there who is capable/willing
> > to help us deliver the library as a debian package, pls. let me
> > know.
>
> Wasn't Morgon Kanter working on 

gnu-crypto.m4. was: new jalopy available

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello Dalibor,

(i'm cc-ing GNU Crypto)

On Sat, 22 Nov 2003 10:51 am, Dalibor Topic wrote:
> ...
> p.s. is there some kind of gnu-crypto.m4 file for automake to add a
> --with-gnu-crypto option to it? I'd love having a simple way to chuck
> in GNU crypto into kaffe without having to bother with those weird
> U.S. crypto laws, as kaffe's CVS server is located in California.

no there isnt but i'm happy to work with you on making one.

things to consider are:

* building gnu crypto is effectively building three jars/libraries: one 
is the gnu-crypto per se (incl. the JCE Adapters), the other two are 
javax-crypto and javax-security (callbacks and sasl).

* once installed in a location (default is /usr/local/gnu-crypto) it 
should be straightforward to construct the different options/switches 
needed by the kaffe build script from the contents of that location.

* it would be nice to be able to re-use most, if not all, of the 
generated options/switches of such an m4 library with other VM 
providers; e.g. kissme and jikes rvm.

if you think this is worth it, let's continue this thread on the GNU 
Crypto list.


cheers;
rsn

p.s. if there is a Debian packager out there who is capable/willing to 
help us deliver the library as a debian package, pls. let me know.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/vqHc+e1AKnsTRiERA66xAJ0dB8LDkuiC1J3tAfdpaz8XZYGoBwCg6J4p
5Zn1P8BCgMQDhN47X0GDwdE=
=9O5u
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: new jalopy available

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Tue, 18 Nov 2003 12:19 pm, Tom Tromey wrote:
> ...
> I made a new release with these improvements.  Once again, it is
> here:
>
> ftp://sources.redhat.com/pub/java/jalopy-console-1.0.4.tar.gz

jalopy is able to handle grouping, and sorting, of class elements 
(e.g.static field and initialisers, instance fields, constructors, 
etc...) and separating them with a 1-line separator (2 with a blank 
line followup).

how (strongly) do people feel about enabling this?


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/voxp+e1AKnsTRiERA67YAKDzb8bjI37+H0Xyaw68A6EFo4dSNACfZIyO
WisJqO0YFNybaStWRqqDHnQ=
=2NPI
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: running GNU Classpath with Jikes RVM

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Monday 31 March 2003 08:02, Raif S. Naffah wrote:
> ...
> i finally got the above combo to work...

if you set a mauve-security input file for Mauve to only exercise the 
java.security packages, rvm completes normally with:

0 of 163 tests failed


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+h2yh+e1AKnsTRiERA7kiAKDXBTqnTiqUrCrW7ZFfymzT65GCmgCfZrVC
PzjS496NQ1buKfkoE70urzc=
=Ex8y
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

running GNU Classpath with Jikes RVM

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello there,

i finally got the above combo to work.  here is what i did with the
usual caveat YMMV.  the main difference with Julian's step-by step
posted some time earlier on the list has to do with configuration
values in step #3 below:


1. checkout the CVS head of GNU Classpath, Mauve and Jikes RVM.  i
shall assume the following:

   GNU Classpath is in $CLASSPATH_SRC/classpath
   Jikes RVM is in $RVM_ROOT/rvm


2. cd $RVM_ROOT/rvm/config

3. edit the file i686-pc-linux.eb as follows (my machine/env is an
athlon-xp single processor, running RH-8.0 with experimental GCC in
/usr/local/gcc):

...
#
# PART I: Preprocessor directives that hold for every config on this target
#
# target architecutre is IA32
export RVM_FOR_IA32=1
export RVM_FOR_32_ADDR=1

# target OS is Linux
export RVM_FOR_LINUX=1

# pthread library will work on our machines so default this to 0.
# NOTE: the key requirement is that you have a 2.4 kernel and
#   that glibc is compiled to use the GS segment register
#   to access pthread-local storage.  See discussion in rvm-researchers 
#   archive and the userguide FAQ.
#export RVM_FOR_SINGLE_VIRTUAL_PROCESSOR=0
export RVM_FOR_SINGLE_VIRTUAL_PROCESSOR=1
...

the rest of the file should reflect your environment.


4. create a .rvmrc somewhere where it's visible from your std $PATH.  i
put it in $HOME.  it must contain the followings:

# .rvmrc

export RVM_ROOT=/data/workspace/cvs/rvmroot
export RVM_HOST_CONFIG=/data/workspace/cvs/rvmroot/rvm/config/i686-pc-linux.eb
export RVM_TARGET_CONFIG=/data/workspace/cvs/rvmroot/rvm/config/i686-pc-linux.eb
export RVM_BUILD=/data/workspace/cvs/build-rvm
export PATH=/data/workspace/cvs/rvmroot/rvm/bin:$PATH


5. source the above.

6. run the JikesRVM config script like so:

jconfigure -D RVM_WITH_GNU_CLASSPATH=1 BaseBaseSemiSpace


7. cd to $RVM_BUILD

8. run the build script like so:

./jbuild

optionally feeding it -trace


9. configure and run Mauve the usual way.


i do get an out-of-memory error and a stack trace, but that's much
better than a hang.


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+h2l8+e1AKnsTRiERA1gIAKCU4GsqR/r57boQjaLSLSdL8aV9DACg0Y8U
wWJGbrAu5IC1pCEUq5LL0xI=
=nUss
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: classpath ./ChangeLog ./THANKYOU ./configure.in...

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello David,

On Monday 31 March 2003 06:13, David P Grove wrote:
> All of the java.security tests are passing on Jikes RVM with the cvs
> head of classpath & mauve...

can you post the build/test script, or point me to its location.  i 
tried building and running rvm but i consistently get an apparent hang 
when invoking a freshly built binary.


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+h1XY+e1AKnsTRiERA/W4AJ9ZVIOF1FJwtOt4jt/Z1dCqk1rECgCgrM2Q
m+Gq1VQTd0aAhnhOOc7n5/A=
=/gYd
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: classpath ./ChangeLog ./THANKYOU ./configure.in...

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Sunday 30 March 2003 02:18, Brian Jones wrote:
> "Raif S. Naffah" <[EMAIL PROTECTED]> writes:
> > On Saturday 29 March 2003 18:27, Brian Jones wrote:
> > > Tom Tromey <[EMAIL PROTECTED]> writes:
> > > > >>>>> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
> > > >
> > > > Brian> There are still some getInstance problems with some of
> > > > the Brian> things I recently checked in though a check through
> > > > my Mauve Brian> results appears to indicate nothing terribly
> > > > new here.
> > > >
> > > > Are these getInstance problems revealed by Mauve?
> > > > Or did you find them some other way?
> > > > I'd like to put all this java.security stuff into libgcj, but
> > > > I'd also prefer to wait if there is a regression that will be
> > > > ironed out soon...
> > >
> > > I looked at the Mauve results before and after and essentially
> > > the same getInstance problems and I don't know much about it
> > > other than that.  It could just be because I don't have
> > > gnu-crypto configured with the mauve testing.  Need to
> > > investigate.
> >
> > the Mauve tests for the getInstance() methods (at least those i
> > added recently) do not rely/depend on GNU Crypto.  all the
> > testcases, install their own, temporary, providers.
> >
> > to test the patch i submitted earlier, i used my local copy of gcc,
> > to which i applied the same patch.  all the security related Mauve
> > tests passed.
>
> It's broken under Kissme/Classpath.

i was unable to test with Kissme because the latter is broken (at least 
in my env).  the only reliable way of testing i found was to do as 
suggested above --i.e. apply the same patch to the gcc/libjava tree-- 
and then run the gcc make check with:

$ MAUVEDIR=path/to/your/mauve/dir make check RUNTESTFLAGS="mauve.exp"

of course this may not be appropriate for Classpath (and non-GCJ) 
specific patches.


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+hiQv+e1AKnsTRiERA1yqAJ9l/v8HuzsXIqgsRa6UX1FpBZwI6ACgprWx
XooGZAOpo1PK1usovwxOp+o=
=wgwH
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: classpath ./ChangeLog ./THANKYOU ./configure.in...

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Saturday 29 March 2003 18:27, Brian Jones wrote:
> Tom Tromey <[EMAIL PROTECTED]> writes:
> > > "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
> >
> > Brian> There are still some getInstance problems with some of the
> > Brian> things I recently checked in though a check through my Mauve
> > Brian> results appears to indicate nothing terribly new here.
> >
> > Are these getInstance problems revealed by Mauve?
> > Or did you find them some other way?
> > I'd like to put all this java.security stuff into libgcj, but I'd
> > also prefer to wait if there is a regression that will be ironed
> > out soon...
>
> I looked at the Mauve results before and after and essentially the
> same getInstance problems and I don't know much about it other than
> that.  It could just be because I don't have gnu-crypto configured
> with the mauve testing.  Need to investigate.

the Mauve tests for the getInstance() methods (at least those i added 
recently) do not rely/depend on GNU Crypto.  all the testcases, install 
their own, temporary, providers.

to test the patch i submitted earlier, i used my local copy of gcc, to 
which i applied the same patch.  all the security related Mauve tests 
passed.


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+hZBE+e1AKnsTRiERA4D8AKDMx3nwhNHKZcw9v8VHaTtLFky7KgCgifot
weqI0s9rNYgv/3fwpYsgzdk=
=JVat
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [PATCH] java.security miscellany

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello Casey,

On Sunday 09 March 2003 08:07, Casey Marshall wrote:
> Attached are the java.security patches I posted earlier...

some of thoses clash/overlap with the patches i'm in the process of 
testing (writing Mauve test cases) and committing in Classpath.

can you defer yours until i finish committing mine --which should be by 
the end of today?


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+anv4+e1AKnsTRiERA8xRAJwICkQEsonPjPgef3pjIMpRPHvj/gCgwwHI
gifpMfhkXgHg/HFBaIaCmiw=
=3lEJ
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Classpath 0.05 beta1

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello Tom,

On Tuesday 11 February 2003 05:44, Tom Tromey wrote:
> >>>>> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
>
> Raif> the patch for the BigInteger i posted sometime ago has not been
> Raif> applied yet.
>
> If you mean the patch you submitted for gcj, I'll put it in this
> week. Sorry for the delay on that; I've been avoiding patch review
> for a while :-(

i did.  but i did not mean it as a blame.  i know you're busy doing a 
million other things and your TODO list is probably a mile long.  hence 
my reference to the patch being applied soon :-)


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+R/s9+e1AKnsTRiERA4zTAKDB5a4G+GG0wpWLYNMhBTMVaW7MnQCgiZPe
XXbha80EzYo3uTQmSj7a4UY=
=TFgi
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Classpath 0.05 beta1

[Raif S. Naffah]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

hello Brian,

On Monday 10 February 2003 11:14, Brian Jones wrote:
> All,
>
> I've posted the first beta of Classpath 0.05...

the patch for the BigInteger i posted sometime ago has not been applied 
yet.  this i assume is going to happen soon, since it has been 
approved.  the delay is because i dont have write access to the gcc 
CVS, but only to Classpath.

still, it would be nice to have that patch included in the final release 
of Classpath, since it improves the performance of BigInteger.


cheers;
rsn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE+R18X+e1AKnsTRiERA/LZAKDbk2R2Xpoyzo0XfnMho2seNqyCXgCgjFgo
JXn9A2VNFRnfOKw+ueYxjN8=
=hrj6
-END PGP SIGNATURE-



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: GNU Crypto

[Raif S. Naffah]

Adam Megacz wrote:
> "Raif S. Naffah" <[EMAIL PROTECTED]> writes:
> 
>>beacuse it does not always follow the published interfaces of Sun, the 
>>library includes a sub-package (gnu.crypto.jce.*) that contains Adapters 
>>for allowing plugging the appropriate algorithms into a JCA/JCE 
>>implementation as a Security Provider (GnuCrypto)
> 
> 
> Yep, BC works the same way...
> 
> I dunno, it just strikes me as strange how there are so many seperate
> open source implementations of the same set of primitives... (RSA,
> RC4, MD5, SHA1, etc...).

i think the criterion to use is not what are the common algorithms but 
what are the non-common ones.  the "usual" algorithms (MD5, SHA, RSA, 
etc.) are there to ensure interoperability with a JDK.

when i started this project BC, Cryptix and others were all there; but 
unlike this project, they are not GNU --may be that was the reason why 
this project was accepted as a GNU one?

in any case, the sources are there for whoever/whatever project may 
benefit from it.


cheers;
rsn


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: GNU Crypto

[Raif S. Naffah]

Adam Megacz wrote:
> Nic Ferrier <[EMAIL PROTECTED]> writes:
> 
>>Eventually there will be a GNU Java JCA/JCE implementation using
>>these. By that time we will probably be delivering a comprehensive
>>GNU java platform.
> 
> 
> Hrm, is there a reason why the GNU Crypto project hasn't simply
> adopted the Bouncy Castle libraries (bouncycastle.org)? I've been
> using them for six months now and found them to be very high quality.

GNU Crypto is *not* a JCA/JCE implementation.  as is mentioned in its 
home page:

"...(GNU Crypto) aims at providing free, versatile, high-quality, and 
provably correct implementations of cryptographic primitives and tools 
in the Java programming language for use by programmers and end-users."

beacuse it does not always follow the published interfaces of Sun, the 
library includes a sub-package (gnu.crypto.jce.*) that contains Adapters 
for allowing plugging the appropriate algorithms into a JCA/JCE 
implementation as a Security Provider (GnuCrypto) --we ear-marked 
BouncyCastle, Cryptix and JDK1.4 JCA/JCE publishers for future integration.

(currently there are only Adapters for the *built-in* hash, PRNG and 
signature schemes.  Adapters for the javax.security interfaces and 
classes will come later.)


cheers;
rsn


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: GNU Crypto

[Raif S. Naffah]

hello Mark,

Mark Wielaard wrote:
> Hi,
> 
> On Sun, 2002-07-21 at 22:14, Raif S. Naffah wrote:
> 
>>Is therre an interest in incorporating the GNU Crypto library 
>><http://www.gnu.org/software/classpathx/crypto/crypto.html> in other GNU 
>>project(s)?
> 
> 
> Yes that would be nice. GNU Classpath (which is being merged with
> libgcj) has a very basic Security Provider for SHA, MD5, DSA and a
> simple Der reader/writer. I just fixed a couple of typos that prevented
> some classes from ever getting actually loaded which indicates that they
> are not really used much in real code and might be buggy. Do you have
> testcases/programs for your package?

yes. there are JUnit test-cases for almost everything in the code --the 
test cases are in the test.* package hierarchy and get jarred in 
gnu-crypto-test.jar.  certain algorithms that do not have published test 
vectors are so marked in the page referrenced above.


> Mark Benvenuto wrote most of the java.security stuff but I don't know if
> he is still around on the mailinglist. If he doesn't speak up on the
> mailinglist you might want to contact him to ask about the status of the
> current Classpath implementations ([EMAIL PROTECTED] or
> [EMAIL PROTECTED]).

i'll wait til the end of this week before contacting him.


> I don't know which crypto algorithms a java implementation should at
> least support (I know the SHA MessageDigest is actually used for
> serialVersionUIDs). But maybe we can import those into GNU Classpath
> directly. It would make sense to at least add pointers to the GNU crypto
> package to the documentation and make it as easy as possible for a user
> that uses GNU Classpath with a certain VM to add the GNU crypto package
> as an additional provider. For gcj it would be nice if GNU crypto was
> available as a shared library that could just be installed by the user
> to get access to the advanced cryptography classes. The security
> provider architecture should make this easy but I have never done it
> with any of the free VMs.

the main build tool for gnu.crypto is ANT but there are Makefile files 
to (a) use GNU Make for building the normal jars, and (b) build 
libraries with GCJ --Olivier is taking care of that part.  we are 
currently cleaning up those files for an eminent release.


> Note that I couldn't download the package since the links on your
> homepage don't work (404 for the current version links) or don't provide
> the actual distribution (for ftp.gnu.org/pub/gnu/classpathx).

yes.  there is still no public release.  the only way to the sources, so 
far, is through CVS --a pointer is available from the project's home 
page above.


> Cheers,
> 
> Mark


cheers;
rsn


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

GNU Crypto

[Raif S. Naffah]

hi there,

Is therre an interest in incorporating the GNU Crypto library 
 in other GNU 
project(s)?


cheers;
rsn


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath