Java guru question

[L. Adrian Griffis]

On Sat, 21 Jun 2003, Jason Clinton wrote:
> >Do you have any idea what the specific things are that are being
> >disallowed and result in the application failing?  Is there an
> >Exception and stack trace that you could show us?
> >
> Sure thing:
> 
> java.lang.SecurityException: class "com.ibm.eNetwork.HODUtil.services.> 
config.client.IllegalOperationException"'s signer information does > not match signer information 
of other classes in the same package
> 	at java.lang.ClassLoader.checkCerts(ClassLoader.java:568)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:496)
> 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
> 	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:148)
> 	at sun.plugin.security.PluginClassLoader.findClass(PluginClassLoader.java:168)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> 	at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)

Looks like this is not a matter of the configuration of the security
manager.  It appears to be a problem with the codebase you are loading
for the applet.  The exception is telling you that the classes within
the package "com.ibm.eNetwork.HODUtil.services.config.client" are not
all signed with the same key.  This is odd, to me, because Java should
load all classes in the same package from the same codebase, and the
key checking is generally only done for packages loaded from a ".jar"
file.  This suggests to me that the ".jar" file in question contains
class files from the same package that are signed by different keys,
inspite of the fact that they are all in that same ".jar" file.  In
other words, someone did a poor job of creating the ".jar" file.  It
may be that this applet works in some browsers simply because they
don't check the signatures as carefully for consistency.

If that's not the explanation, it occurs to me that the message might
be a little misleading.  It could be that your browser doesn't know
to trust the signatures, it may be incorrectly characterizing the
problem as a signature consistency problem rather than simply a
problem of not recognizing the signing key at all.  Did you have to
go through any process of telling your browser to recognize a new
signing key for this application?  I don't know exactly what that
process would be like, but it seems to me your browser must have some
way to tell the difference between signing keys it should trust and
those that it should not trust.  Unless there's a chain of signatures
back to something you already had installed, you might have had to
do something new to tell them what to do with a new signing key for
that application.

It could also be that the application is signed incorrectly in some
way within the ".jar" file, but that it needs no special privileges,
and the signatures don't really matter.  Maybe the browsers that run
the application successfully simply ignore the signature problem and
refuse to grant the application special privileges.  Your browser
recognizes the problem with the unnecessary signature, and rejects
the applet.

In any caes, I think this is not a simple matter of the security
manager not being configured to permit the same operations by an
applet.  This has something to do with a check for signatures so
that the applet could potentially be granted additional privileges.
The exception is originating in this check of signatures.

I hope this helps.

Adrian