Java Web Start and Eclipse - Signing Jars and Hibernate

As a quick note:

If you are deploying an Eclipse Plugin as a Java Web Start, there are some changes that must be made to your application to ensure it plays well with everything.

This is the first of a few quick notes on the subject. I am starting with this issue, since it was the most difficult to find a resolution for.

My environment background is as follows:

• Eclipse v3.2.1
• hibernate plugin : com.hibernate.eclipse_3.2.0.beta9a
• JDK 1.5.0_10

Java Web Start is basically a tool that Sun provides that allows users to run Java applications that have been bundled in Jars on their computers. It has limitations similar to those imposed upon Java Applets, but if the jars are signed, then the Java Security Manager can grant full access to all resources on the local computer. It may take a while to download numerous signed jars and verify their signatures, but once they are downloaded, rerunning the application the start time can be measured in a matter of seconds instead of minutes. JWS also provides nice features for updates and utilization of different JDK versions.

Jar Files MUST be Signed
------------------------

All jar files that are being deployed must be signed if your application must access resources outside of the sandbox. If a jar file is to be expanded on the client's computer, all nested jars must also be signed.

Java, at least 1.5 and lower, cannot deal with nested jar files. When such a situation occurs, as with the Hibernate plugin for Eclipse, Xerces, or even the Eclipse core plugin for example, the jar file must be expanded before the resources can be accessed. When the contents of a jar file is expanded, the resources it contains is no longer digitally signed (if it was decompressed, it will not match the digital signature). This is an issue for the nested jars, since they generally must be signed.

The only exception to this rule is with the Eclipse Hibernate plugin. The two jar files that cannot be signed are: hibernate3.jar and cglib-2.1.3.jar. If these two jars are signed, the following exception will result:

java.lang.SecurityException: class "com.mypackage.MyClass$$EnhancerByCGLIB$$a1a0f853"'s

signer information does not match signer information of other classes in the same package

The key part of the above error message being "signer information does not match signer information of other classes in the same package".

A side note:
------------

I am unable to find the reference that states all nested jars must be signed (it is also a low priority to find it). Signing nested jars files works with the exception above. Upon searching for the problem as listed with the ‘signer information does not match’ exception, I have found that many other people have also signed the nested jars before exporting the plugins out of Eclipse.

To me this just sounds wrong on a few levels. I have not had the chance to really test this theory by unsigning these plugins, but it will solve that question. If it does work without signing the nested jars, then it does make sense that when JWS initially expands the jars, it keeps track of the original signature and that all expanded resources has having passed the verification.

If you have references that point to the fact that nested jars do not need to be signed, please let me know. I will probably run some tests in the next week or two to verify this.

References:
-----------

http://groups.google.co.za/group/CTJUG-Forum/tree/browse_frm/month/2006-05?_done=%2Fgroup%2FCTJUG-Forum%2Fbrowse_frm%2Fmonth%2F2006-05%3F&

States that "Never sign hibernate???.jar and cglib???.jar. They seem to work just fine as they are."

http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/development.html#security

http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/contents.html