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

Adrian Brock abrock at redhat.com
Thu Feb 25 08:27:04 EST 2010


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/classloader/src/main/java/org/jboss/classloader/spi/base/BaseClassLoader.java
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.

-- 
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx




More information about the jboss-development mailing list