security providers and ...

security providers and ...

[Vladimir Puskas]

Hi!

I've managed to compile a fairly large application. Now, I search things that 
could be improved, as well those that still don't work as they should. 
WebDocWf is pure Java project based on Enhydra, Tomcat, Xerces etc. It runs 
from bytecodes, as Win32 binary, and now as GNU/Linux binary.

Now, my troubles are:
1) The 'gnu.java.security.provider.Gnu' says that it supports MD5 beside 
other things but 'gnu.java.security.provider.MD5' simply isn't there. I 
needed it bad enough, so I did merge it myself from GNU Classpath. And, while 
on this subject: pardon my ignorance, but only way to initialize security 
provider I found, is to call addProvider in my source. This isn't a problem 
to me, but it differs to Sun's VM, where I don't need:
 java.security.Security.addProvider(new gnu.java.security.provider.Gnu());

2) There are two classes I've copied from GNU Classpath too:
 java.awt.print.PrinterIOException and java.awt.print.PrinterException

3) Enhydra has it's own classloader, it tries to load classes and fails if I 
remove them from classpath, then secondary/system classloader succedes 
because class is compiled and linked. I would like to have an opportunity to 
prevent it's useless operation by knowing if a class is already loaded 
(compiled into binary). Question is:
Can I at runtime, know where class is loaded from? Has it been in shared 
library or class/jar file?

TIA
Vladimir Puskas <vpuskas@eunet.yu>

Re: security providers and ...

[Tom Tromey]

>>>>> "Vladimir" == Vladimir Puskas <vpuskas@EUnet.yu> writes:

I didn't see a response to this.

Vladimir> 1) The 'gnu.java.security.provider.Gnu' says that it
Vladimir> supports MD5 beside other things but
Vladimir> 'gnu.java.security.provider.MD5' simply isn't there.

That must be an oversight or missed merge opportunity.  Sorry about
that.

Vladimir> I needed it bad enough, so I did merge it myself from GNU
Vladimir> Classpath. And, while on this subject: pardon my ignorance,
Vladimir> but only way to initialize security provider I found, is to
Vladimir> call addProvider in my source. This isn't a problem to me,
Vladimir> but it differs to Sun's VM, where I don't need:
Vladimir> java.security.Security.addProvider(new
Vladimir> gnu.java.security.provider.Gnu());

This is probably a bug in our java.security implementation.

Actually, I seem to remember fixing this at some point.  Perhaps the
fix got lost.  Or maybe I just did it as a temporary hack somewhere.

Vladimir> Question is:
Vladimir> Can I at runtime, know where class is loaded from? Has it
Vladimir> been in shared library or class/jar file?

As far as I know there isn't a way to do this from Java.
You could probably do it in C++ by digging around in internal data
structures.  I doubt there is an "approved" way to do this, but if we
knew what you needed to do maybe we could make one.

Tom

Re: security providers and ...

[Vladimir Puskas]

Sorry, I've left without an answer. Usually I don't act this way. Job took my 
attention elsewhere, but now I'm back.

On Monday 06 May 2002 23:45, Tom Tromey wrote:
> >>>>> "Vladimir" == Vladimir Puskas <vpuskas@EUnet.yu> writes:
>
> I didn't see a response to this.
>
> Vladimir> 1) The 'gnu.java.security.provider.Gnu' says that it
> Vladimir> supports MD5 beside other things but
> Vladimir> 'gnu.java.security.provider.MD5' simply isn't there.
>
> That must be an oversight or missed merge opportunity.  Sorry about
> that.

I get my GCC/GCJ by downloading weekly snapshot and building it.
As far as I know, classes I have mentioned, aren't there. To remedy this I'll 
send them to the list, or whereever you advise me. Last time I haven't 
offered this because they are part of GNU Classpath project, and I expected 
someone would merge them.

> Vladimir> Question is:
> Vladimir> Can I at runtime, know where class is loaded from? Has it
> Vladimir> been in shared library or class/jar file?
>
> As far as I know there isn't a way to do this from Java.
> You could probably do it in C++ by digging around in internal data
> structures.  I doubt there is an "approved" way to do this, but if we
> knew what you needed to do maybe we could make one.

My idea was to intercept Enhydra's classloader and prevent it loading a class, 
if class is already compiled and linked into binary. Classloader supports 
filtering which would perfectly match this task, but I couldn't find the 
method to do this.
Anyway, this feature (intended to be optimization step) has fell down on my 
task list, since new Enhydra 5.0 (Aonyx) is released.

Regards,
Vladimir Puskas

Re: security providers and ...

[Jeff Sturm]

On Tue, 9 Jul 2002, Vladimir Puskas wrote:
> My idea was to intercept Enhydra's classloader and prevent it loading a class,
> if class is already compiled and linked into binary. Classloader supports
> filtering which would perfectly match this task, but I couldn't find the
> method to do this.

That's the default behavior of ClassLoader.loadClass(), it searches
compiled classes before attempting to load bytecode.  Well-behaved
classloaders will delegate to the parent first, often the system
classloader, so you shouldn't have to do anything out of the ordinary.

Jeff

Re: security providers and ...

[Mark Wielaard]

Hi,

On Tue, 2002-07-09 at 15:45, Vladimir Puskas wrote:
> On Monday 06 May 2002 23:45, Tom Tromey wrote:
> > >>>>> "Vladimir" == Vladimir Puskas <vpuskas@EUnet.yu> writes:
> >
> > I didn't see a response to this.
> >
> > Vladimir> 1) The 'gnu.java.security.provider.Gnu' says that it
> > Vladimir> supports MD5 beside other things but
> > Vladimir> 'gnu.java.security.provider.MD5' simply isn't there.
> >
> > That must be an oversight or missed merge opportunity.  Sorry about
> > that.
> 
> I get my GCC/GCJ by downloading weekly snapshot and building it.
> As far as I know, classes I have mentioned, aren't there. To remedy this I'll 
> send them to the list, or whereever you advise me. Last time I haven't 
> offered this because they are part of GNU Classpath project, and I expected 
> someone would merge them.

Sorry that we missed this. I have just added the missing
gnu.java.security classes (plus a couple of small updates) to libgcj
CVS. But I don't think they are very well tested so please let us know
if they work correctly for you.

Thanks,

Mark

Re: security providers and ...

[Vladimir Puskas]

On Monday 15 July 2002 00:19, Mark Wielaard wrote:
> But I don't think they are very well tested so please let us know
> if they work correctly for you.
>

gnu.java.security.provider.MD5 should extend java.security.DigestMessage 
instead of DigestMessageSpi, because now it throws exception:
java.lang.ClassCastException:
 gnu.java.security.provider.MD5 cannot be cast to java.security.MessageDigest
when trying to MessageDigest.getInstance("MD5").

public class t  {
	public static void main(String[]argv) {
		try {
			java.security.MessageDigest.getInstance("MD5");
		} catch(Throwable t) {
			t.printStackTrace();
		}
	}
}

Bellow are the changes I made to get it work. Can you, please, commit them?
V.Puskas

===================================================================
--- cvs/libjava/gnu/java/security/provider/MD5.java	Sun Aug 11 14:08:03 2002
+++ gcc/libjava/gnu/java/security/provider/MD5.java	Fri Aug 16 00:46:35 2002
@@ -37,14 +37,14 @@
 
 
 package gnu.java.security.provider;
-import java.security.MessageDigestSpi;
+import java.security.MessageDigest;
 
 /**
    This class implements the MD5 algorithm as described in RFC1321.
 
    @see java.security.MessageDigest
 */
-public class MD5 extends MessageDigestSpi implements Cloneable
+public class MD5 extends MessageDigest implements Cloneable
 {
   private final int W[] = new int[16];
   private long bytecount;
@@ -55,7 +55,7 @@
 
   public MD5()
   {
-    super();
+    super("MD5");
     engineReset ();
   }

Re: security providers and ...

[Raif S. Naffah]

Vladimir Puskas wrote:
> On Monday 15 July 2002 00:19, Mark Wielaard wrote:
> 
>>But I don't think they are very well tested so please let us know
>>if they work correctly for you.
> 
> gnu.java.security.provider.MD5 should extend java.security.DigestMessage 
> instead of DigestMessageSpi, because now it throws exception:
> java.lang.ClassCastException:
>  gnu.java.security.provider.MD5 cannot be cast to java.security.MessageDigest
> when trying to MessageDigest.getInstance("MD5")...
> 
> Bellow are the changes I made to get it work...

pls be aware that if you incorporate this change, implementations of 
message digests not already in the java.security package (e.g. in 
gnu.crypto) will fail in the same way.

i think the cure is:

1. to catch the ClassCastException,
2. test if the newly instantiated class is an instance of 
java.security.MessageDigestSpi,
3. if it isnt re-throw the exception, otherwise
4. wrap the newly instantiated class in a proxy class that channels the
MessageDigest calls to the wrapped Spi (inner) class.


cheers;
rsn

Re: security providers and ...

[Tom Tromey]

>>>>> "Raif" == Raif S Naffah <raif@fl.net.au> writes:

Raif> i think the cure is:

Raif> 1. to catch the ClassCastException,
Raif> 2. test if the newly instantiated class is an instance of
Raif> java.security.MessageDigestSpi,
Raif> 3. if it isnt re-throw the exception, otherwise
Raif> 4. wrap the newly instantiated class in a proxy class that channels the
Raif> MessageDigest calls to the wrapped Spi (inner) class.

This seems reasonable to me, but then I don't really know that much
about java.security :-).  Could you submit a PR for this problem?  Or,
if you like, a patch?

Tom

Re: security providers and ...

[Raif S. Naffah]

Tom Tromey wrote:
>>>>>>"Raif" == Raif S Naffah <raif@fl.net.au> writes:
>>>>>
> 
> Raif> i think the cure is:
> 
> Raif> 1. to catch the ClassCastException,
> Raif> 2. test if the newly instantiated class is an instance of
> Raif> java.security.MessageDigestSpi,
> Raif> 3. if it isnt re-throw the exception, otherwise
> Raif> 4. wrap the newly instantiated class in a proxy class that channels the
> Raif> MessageDigest calls to the wrapped Spi (inner) class.
> 
> This seems reasonable to me, but then I don't really know that much
> about java.security :-).  Could you submit a PR for this problem?  Or,
> if you like, a patch?

i'll co-ordinate with Mark (Wielaard) for both.


cheers;
rsn

Re: security providers and ...

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

Hi,

On Fri, 2002-08-16 at 01:28, Vladimir Puskas wrote:
> On Monday 15 July 2002 00:19, Mark Wielaard wrote:
> > But I don't think they are very well tested so please let us know
> > if they work correctly for you.
> >
> 
> gnu.java.security.provider.MD5 should extend java.security.DigestMessage 
> instead of DigestMessageSpi, because now it throws exception:
> java.lang.ClassCastException:
>  gnu.java.security.provider.MD5 cannot be cast to java.security.MessageDigest
> when trying to MessageDigest.getInstance("MD5").

I had actually already done that for Classpath and will do that now also
for libgcj since that makes it at least usable for now. Raif already
send me patches to make MessageDigest handle classes that extend
MessageDigestSpi (and implements algorithm aliases) which is a more
generic solution. We will add that later when we have tested them a bit
more.

Thanks,

Mark

[-- Attachment #2: provider.patch --]
[-- Type: text/x-patch, Size: 1846 bytes --]

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/libjava/ChangeLog,v
retrieving revision 1.1405
diff -u -r1.1405 ChangeLog
--- ChangeLog	14 Aug 2002 19:53:54 -0000	1.1405
+++ ChangeLog	18 Aug 2002 18:26:52 -0000
@@ -1,3 +1,9 @@
+2002-08-18  Mark Wielaard  <mark@klomp.org>
+
+	Thanks to Vladimir Puskas <vpuskas@eunet.yu>
+	* gnu/java/security/provider/MD5.java: Extends MessageDigest, not
+	MessageDigestSpi (fixes Classpath bug #783).
+
 2002-08-14  Jesse Rosenstock  <jmr@ugcs.caltech.edu>
 
 	* java/lang/natPosixProcess.cc (cleanup): Added `path' argument.
Index: gnu/java/security/provider/MD5.java
===================================================================
RCS file: /cvs/gcc/gcc/libjava/gnu/java/security/provider/MD5.java,v
retrieving revision 1.4
diff -u -r1.4 MD5.java
--- gnu/java/security/provider/MD5.java	11 Aug 2002 12:08:03 -0000	1.4
+++ gnu/java/security/provider/MD5.java	18 Aug 2002 18:26:53 -0000
@@ -1,5 +1,5 @@
 /* MD5.java -- Class implementing the MD5 algorithm as specified in RFC1321.
-   Copyright (C) 1999 Free Software Foundation, Inc.
+   Copyright (C) 1999, 2002 Free Software Foundation, Inc.
 
 This file is part of GNU Classpath.
 
@@ -37,14 +37,14 @@
 
 
 package gnu.java.security.provider;
-import java.security.MessageDigestSpi;
+import java.security.MessageDigest;
 
 /**
    This class implements the MD5 algorithm as described in RFC1321.
 
    @see java.security.MessageDigest
 */
-public class MD5 extends MessageDigestSpi implements Cloneable
+public class MD5 extends MessageDigest implements Cloneable
 {
   private final int W[] = new int[16];
   private long bytecount;
@@ -55,7 +55,7 @@
 
   public MD5()
   {
-    super();
+    super("MD5");
     engineReset ();
   }
 

Re: security providers and ...

[Raif S. Naffah]

Vladimir Puskas wrote:
 > Lars Andersen wrote:
 >> Raif S. Naffah wrote:
>>>i think the cure is...
>>
>>...I think the problem is buried somewhere else...
> 
> ...Does it mean SHA should extend MessgeDigestSpi too, or they (SHA & MD5) are
> unrelated?

the former.  any implementation of a class that has a related xxSpi 
(MessageDigest as well as others), should extend/implement the xxxSpi 
base class, as per JDK dox.

cheers;
rsn

Re: security providers and ...

[Lars Andersen]

On Fri, 2002-08-16 at 22:04, Vladimir Puskas wrote:
> > >i think the cure is:
> > >
> > >1. to catch the ClassCastException,
> > >2. test if the newly instantiated class is an instance of
> > >java.security.MessageDigestSpi,
> > >3. if it isnt re-throw the exception, otherwise
> > >4. wrap the newly instantiated class in a proxy class that channels the
> > >MessageDigest calls to the wrapped Spi (inner) class.
> > >
> > >
> > >cheers;
> > >rsn
> >
> > OK, I have noticed the same behaviour, a ClassCastException when
> > requesting the MD5 MessageDigest from the "GNU" security provider, but
> > please consider :
> >
> > 1: the gnu security provider works fine in sun jdk1.4.
> > I tried to use Reflection to see how it was handled, and it returned the
> > type : MessageDigest$Delegate, not just MessageDigest.
> >
> > 2: It only fails in GCJ in static compiled binaries. I have used the GNU
> > MD5 MessageDigest with GCJ compiled binaries, only when i added the
> > -static option did i get this error.
> >
> > I think the problem is buried somewhere else. The MessageDigestSpi class
> > is intended (long time ago...) for security providers to implement
> > MessageDigest implementations.
> >
> >
> > regards
> > Lars Andersen
> 
> I wrote previous message rather quickly, and was not aware of sideeffects.
> Still bug is out there, or maybe two. My patch is based on 
> gnu.java.security.provider.SHA, which extends MessageDigest.
> 
> Does it mean SHA should extend MessgeDigestSpi too, or they (SHA & MD5) are 
> unrelated?
> 
> V.Puskas
> 
> 
> 

Clipped from the j2sdk 1.4 API MessageDigest class :
>>>
-Note that this class is abstract and extends from MessageDigestSpi for
-historical reasons. Application developers should only take notice of
-the methods defined in this MessageDigest class; all the methods in the
-superclass are intended for cryptographic service providers who wish to
-supply their own implementations of message digest algorithms. 
<<<

It should be OK to imlplement from the MessageDigest class; however the
other approach (extending MessageDigestSpi) ought to work as well. It
does so in the sun jdk1.4.

I solved it by writing my own security provider, with SHA-1 and MD5
MessageDigests subclassing java.security.MessageDigest.
This bypasses two problems in GCJ. The one being the MD5 problem, the
other the absence of aliasing in the GNU provider under GCJ.

regards
Lars Andersen

Re: security providers and ...

[Vladimir Puskas]

> >i think the cure is:
> >
> >1. to catch the ClassCastException,
> >2. test if the newly instantiated class is an instance of
> >java.security.MessageDigestSpi,
> >3. if it isnt re-throw the exception, otherwise
> >4. wrap the newly instantiated class in a proxy class that channels the
> >MessageDigest calls to the wrapped Spi (inner) class.
> >
> >
> >cheers;
> >rsn
>
> OK, I have noticed the same behaviour, a ClassCastException when
> requesting the MD5 MessageDigest from the "GNU" security provider, but
> please consider :
>
> 1: the gnu security provider works fine in sun jdk1.4.
> I tried to use Reflection to see how it was handled, and it returned the
> type : MessageDigest$Delegate, not just MessageDigest.
>
> 2: It only fails in GCJ in static compiled binaries. I have used the GNU
> MD5 MessageDigest with GCJ compiled binaries, only when i added the
> -static option did i get this error.
>
> I think the problem is buried somewhere else. The MessageDigestSpi class
> is intended (long time ago...) for security providers to implement
> MessageDigest implementations.
>
>
> regards
> Lars Andersen

I wrote previous message rather quickly, and was not aware of sideeffects.
Still bug is out there, or maybe two. My patch is based on 
gnu.java.security.provider.SHA, which extends MessageDigest.

Does it mean SHA should extend MessgeDigestSpi too, or they (SHA & MD5) are 
unrelated?

V.Puskas

Re: security providers and ...

[Tom Tromey]

>>>>> "Lars" == Lars Andersen <lars@rimfaxe.com> writes:

Lars> 2: It only fails in GCJ in static compiled binaries. I have used
Lars> the GNU MD5 MessageDigest with GCJ compiled binaries, only when
Lars> i added the -static option did i get this error.

For me it fails with bytecode as well.  So it isn't likely to be the
typical -static problem.  I think it is just a generic bug as Raif
diagnosed.

Tom

Re: security providers and ...

[Lars Andersen]

> Vladimir Puskas wrote:
>
>On Monday 15 July 2002 00:19, Mark Wielaard wrote:
>
>
>But I don't think they are very well tested so please let us know
>if they work correctly for you.
>
>gnu.java.security.provider.MD5 should extend
>java.security.DigestMessage instead of DigestMessageSpi, because now it
>throws exception:
>java.lang.ClassCastException:
>gnu.java.security.provider.MD5 cannot be cast to
>java.security.MessageDigest
>when trying to MessageDigest.getInstance("MD5")...
>
>Bellow are the changes I made to get it work...
>pls be aware that if you incorporate this change, implementations of
>message digests not already in the java.security package (e.g. in
>gnu.crypto) will fail in the same way.
>
>i think the cure is:
>
>1. to catch the ClassCastException,
>2. test if the newly instantiated class is an instance of
>java.security.MessageDigestSpi,
>3. if it isnt re-throw the exception, otherwise
>4. wrap the newly instantiated class in a proxy class that channels the
>MessageDigest calls to the wrapped Spi (inner) class.
>
>
>cheers;
>rsn


OK, I have noticed the same behaviour, a ClassCastException when
requesting the MD5 MessageDigest from the "GNU" security provider, but
please consider :

1: the gnu security provider works fine in sun jdk1.4.
I tried to use Reflection to see how it was handled, and it returned the
type : MessageDigest$Delegate, not just MessageDigest.

2: It only fails in GCJ in static compiled binaries. I have used the GNU
MD5 MessageDigest with GCJ compiled binaries, only when i added the
-static option did i get this error.

I think the problem is buried somewhere else. The MessageDigestSpi class
is intended (long time ago...) for security providers to implement
MessageDigest implementations. 


regards
Lars Andersen