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

[Anil Saldhana]

You are right, Brian. Split packages across jars works as long as they 
are both
signed by the same certificates. We have seen signed and unsigned jars
with packages split across them does not work in the JVM.

Our goal should be to reduce package splitting across jars as much as 
possible.
We need to be aware of the packages/jars combination via tattletale such 
that
we can sign the jars and do not miss any jars that may have split packages.

On 02/25/2010 09:01 AM, Brian Stansberry wrote:
> The exception Mike showed is specified in the javadoc of
> java.lang.ClassLoader protected final Class<?>  defineClass(String name,
> byte[] b, int off, int len)
>
> * @throws  SecurityException
> *          If an attempt is made to add this class to a package that
> *          contains classes that were signed by a different set of
> *          certificates than this class (which is unsigned), or if
> *<tt>name</tt>  begins with "<tt>java.</tt>".
>
>
> On 02/25/2010 08:58 AM, Mike Clark wrote:
>    
>> Hey Dimitris,
>>
>>    From what I read, sealing implies that packages must be loaded from a
>> single jar, signed or not.  We do load the same package from multiple
>> jars.  In addition, We should see a "java.lang.SecurityException:
>> sealing violation at java.net.URLClassLoader.defineClass()" [1] in the
>> case of a sealing violation.   So, I think sealing is a red-herring with
>> respect to this discussion.
>>
>> Cheers,
>> Mike C.
>>
>> [1] http://java.sun.com/developer/JDCTechTips/2001/tt0130.html#files
>>
>> On 02/25/2010 08:49 AM, Dimitris Andreadis wrote:
>>      
>>> 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/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.
>>>>>
>>>>>