Jonathan Bruce's Blog

Why sign a jar?

I was recently asked, why would you ever need to sign a jar? What advantage does it give me?

I would like to put this question to the Java.net community: have you seen a need beyond allowing your applications to run with Java WebStart, or perhaps within the confines of an Applet.

Endorsing jars allow youto over-ride classes, and is something I have seen used in the Java Web Services Developer Pack, however the reasons to endorse a jar might often be quite different to why one might sign a jar.

So over to you... I am really interested to hear about used of signed jars that I may not be aware of...

Comments

• I worked on a commercial applet that used signing to enable caching itself, access to OLE for interoperability, reading and writing files, running other programs, printing (not necessary from 1.2) and getting rid of that pesky little banner.

  Signing a jar also gives the average user confidence to trust your software.

  All of the above features were controlled by instructions from the server, so a malicious server could use the applet signed by a reputable company to do as it wished.

  Posted by: tackline on November 08, 2005 at 12:36 PM

• In a J2EE shop here. In our production environments we define a java security policy that grants certain permissions based on the signer of the codebase. In this way, we can be assured that only jars signed by our deployment tool are able to, for example, make database connections.

  Posted by: mmcshane on November 08, 2005 at 12:49 PM

• Here's a situation where a signed JAR hurt me:

  There is a very badly written Java library that I'm using (can't name names). It is so badly designed that the only way I could implement a new feature was if my classes resided in the same package as the some of the classes in the JAR file (due to default accessibility levels). However, I couldn't do this because the JAR was signed so I couldn't "fake" the application into thinking that my classes were in the same package as the ones in the JAR.

  Posted by: zarar on November 08, 2005 at 01:09 PM

• So what I meant to say was: It is difficult to the point of unreasonableness to expect benign code not to be usable in malicious ways, even if you get a warm fuzzy feeling from the signing.

  Posted by: tackline on November 08, 2005 at 02:34 PM

• So zarar's example is a valid use for signing and sealing a jar... Prevent downstream users from re-defining any of your classes (or in his case, defining new classes in the same package).

  Posted by: lhankins on November 08, 2005 at 08:59 PM

• One example I can think of.. a user tries to install our Java Swing app (using Install4J) and the new Windows XP SP2+ now puts up a dialog about unknown publisher. With a signed app, this wouldn't be the case.. I don't believe. We are planning on signing our app for this reason alone.
  

  Posted by: buckman1 on November 09, 2005 at 01:00 AM

• buckman: I imagine you are planning on signing the Intall4J executable, though, aren't you? Rather than the jars in your app?

  Posted by: grlea on November 09, 2005 at 03:50 PM

• Hey everyone - thank you so much for your excellent feedback. This is given me some very interesting points of consideration...

  Posted by: jonbruce on November 10, 2005 at 06:36 AM

This work is licensed under a Creative Commons License.