Re: [jboss-dev] Refactoring packaging/packages to reduce "signed jar groups"

Could it be that signing implies package sealing? Can you tried setting explicitly sealing to off? Mike Clark wrote: > 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. >> >> >> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development