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.
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx