incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <>
Subject Re: Signing Java Jars, versus Apache Signing of distributed artifacts
Date Mon, 20 Aug 2007 19:35:05 GMT
Craig L Russell wrote:
> Hi Marshall,
> When I looked into Java signing and found it to be too burdensome. 
> There are two basic issues with it that made me think that it wasn't 
> suitable for use with Apache projects:
> 1. The certificates are the keys to the kingdom. Whoever has the 
> ability to use the certificates warrants the contents of the jar, so 
> the certificates need to be kept secret. It's not practical for Apache 
> projects to have secrets like this, so each individual would need 
> their own certificate.
I don't quite follow.  My understanding is that the signing key can be 
like Apache's signing keys - each person can have their own individual 
signing key, just like Apache ones.  The difference is that there is an 
additional step where you have to get the key "certified" by a 
certificate authority.
I think that, at verification time, this authority is contacted to 
verify the signing key is owned by the alleged owner. 

Did you mean by your comment that the part of the Apache license 
(Section 7), "Disclaimer of Warranty", is inconsistent with Jar signing, 
because the signer "warrants" the contents of the Jar?
> 2. The runtime cost of checking the certificate every time the jar is 
> used.
Right- so this would need to be examined.  For Jars packaged for use by 
Eclipse (say, for instance, doing an Eclipse "Update Site" for
Eclipse plugins that might be a part of your project, Eclipse seems to 
have solved this problem in how they use class loaders (see references 
in originial note).

Thanks for your opinion.  -Marshall
> Just my opinion,
> Craig
> On Aug 20, 2007, at 8:54 AM, Marshall Schor wrote:
>> I'm no expert in signing, but am looking into alternatives.  This is 
>> what I've found, so far.
>> Apache projects sign their distributable artifacts; see 
>> For artifacts which are Jars, there is another standard for signing 
>> which is supported by Java itself, in that the signed Jar can be 
>> "verified" when loaded.  This kind of signing
>> requires, besides the "private key", a "certificate
>> authority" which  indicates who owns the key.  See 
>> Apache signing, to my knowledge, doesn't require use of a certificate 
>> authority.
>> In looking at several projects placing Jars in Maven repositories, 
>> they appear to be signing
>> Jars using the Apache signing, not the Java Jar signing mechanism.  
>> Maven (I believe)
>> supports this.
>> Eclipse, as of release 3.3 (just out), has moved to a posture of 
>> signing all of its Jars using the Java mechanisms, see 
>> There are some issues to signing Jars with Java's approach - in terms 
>> of performance impacts.  These are documented here: 

>> Eclipse avoids these performance impacts by not using the popular 
>> Java class loaders
>> built on the URLClassLoader.
>> I'd be interested to learn if others have gone down the Java JAR 
>> signing path, and if so,
>>  - is it considered an OK alternative to Apache signing,
>>  - how did you get a certificate authority to verify ownership of 
>> your signing key
>>  - how did you avoid performance issues
>> If not - does anyone know if the Eclipse update site mechanism 
>> supports the Apache-style signing mechanism, or can be made to 
>> support this?  (The Eclipse update site mechanism checks if the 
>> artifacts have been signed, and if so, verifies them, prior to 
>> installing them.  But I believe it only works with Java JAR signed 
>> objects - but I could be mistaken).
>> Thanks for any guidance / experiences.
>> -Marshall Schor (Apache UIMA project)
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> Craig Russell
> Architect, Sun Java Enterprise System
> 408 276-5638
> P.S. A good JDO? O, Gasp!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message