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 http://www.apache.org/dev/release-signing.html

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 http://java.sun.com/docs/books/tutorial/deployment/jar/intro.html

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 http://wiki.eclipse.org/JAR_Signing

There are some issues to signing Jars with Java's approach - in terms of performance impacts. These are documented here: http://wiki.eclipse.org/index.php/Performance_Bloopers#JAR_signing_and_verification

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to