Hey Adrian,
From reading the links you provided, it doesn't seem to be a sealed
package thing. Indeed, we do not seal the jars. The error is, for example:
2010-02-25 08:36:00,520 INFO [org.jboss.web.WebService] (main) Using
RMI server codebase:
http://127.0.0.1:8083/
2010-02-25 08:36:00,621 WARN
[org.jboss.detailed.classloader.ClassLoaderManager] (main) Unexpected
error during load of:org.jboss.naming.NamingService
java.lang.SecurityException: class "org.jboss.naming.NamingService"'s
signer information does not match signer information of other classes in
the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at
org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at
org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
at
org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
at java.security.AccessController.doPrivileged(Native Method)
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
at
org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at
org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at
org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
at
org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:267)
at
org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:166)
at
org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
at
org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
(This is from line 2 of the server.log when you replace jboss.jar in EAP
5 with an unsigned version.)
Cheers,
Mike C.
On 02/25/2010 07:27 AM, Adrian Brock wrote:
On Wed, 2010-02-24 at 16:50 -0600, Mike Clark wrote:
> Hey folks,
>
> The general purpose of this note is to explore refactoring some of our
> jars to reduce some problems that have come about due to our signing
> of jars.
>
<snip/>
> The problem with such a substitution is the fact that a classloader
> will not load classes from a packages that appear in differently
> signed jars. So, for example, even though class org.jboss.A may only
> occur in an unsigned A.jar, loading it will cause a security exception
> if class org.jboss.B was loaded from a signed B.jar.
>
I don't understand this, what error message are you seeing?
Signing jars (which is about verifying the bytes have not been
tampered with - and potentially granting additional security
permissions)
http://java.sun.com/docs/books/tutorial/deployment/jar/intro.html
has nothing to do with what you describe, which sounds like package
sealing?
http://java.sun.com/docs/books/tutorial/deployment/jar/sealman.html
See definePackage() here:
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloade...
for how we currently implement package sealing.
AFAIK, Package::isSealed(URL) just does an equals check on the URL,
it doesn't look at the CodeSource's certificates.