Re: Signing Java Jars, versus Apache Signing of distributed artifacts
I'm looking for a resolution to this also. Chainsaw (a log file viewer from the Logging Services project) has been available via WebStart from the Logging Services web site for several years but is signed by one of the developer's personal certificates. It doesn't seem to fit within the release guidelines (not mirrored, not archived, not reproducible) and it seems hard to make it fit. See http://marc.info/?l=log4j-devm=118772583611470w=2 for today's discussion. Using Chainsaw using WebStart would require signing as access to local files and the network is pretty much essential to operation. Had a similar situation with log4net which had a .NET strong name key that had been used to prepare earlier versions of log4net which had been in the exclusive control of one developer which would prevent the project from releasing compatible builds if he had been hit by the fabled bus. The strong name key file was encrypted so that it could be decrypted by using the signing keys of several of the developers and placed in the SVN repo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Signing Java Jars, versus Apache Signing of distributed artifacts
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. 2. The runtime cost of checking the certificate every time the jar is used. 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! smime.p7s Description: S/MIME cryptographic signature
Re: Signing Java Jars, versus Apache Signing of distributed artifacts
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]
