View source for JAR Signing

== Overview ==
We are working towards signing Eclipse builds for the 3.2 Callisto release.  The goal of signing is to allow users to verify that the content they obtain from eclipse.org and subsequently execute does indeed come from that source. Signing in a nutshell works as follows:

# Eclipse builds produce content in various forms (zips, update JARS)
# The Eclipse Foundation produces a signature of the build content using its private key (signature = private key + content)
# User downloads build content and signatures from eclipse.org or from mirrors
# The Eclipse Foundation makes available a [http://en.wikipedia.org/wiki/Public_key_infrastructure public key] for verifying signatures
# User consults some trusted authority to verify that the public key does indeed belong to the Eclipse Foundation
# Verification is performed on the user's machine (signature + public key = hash of content)

== Open problems ==

=== What gets signed? ===

The two principal outputs from the build process are update site JARs and stand-alone zips.

==== Signing stand-alone zips ====
''This is a bit of a misnomer.  We really want to sign the Java code jars.  If they happen to be in the zip, so be it.  Signing of DLLs and EXEs is a separate problem that we are not tackling for stand-alone zips or update site based installs''

The problem with stand-alone zips is that there is no opportunity to perform verification at download time.  The user would need to take a manual step to run verification on the zip before unzipping and using it.  Note that signing only the JARs within the stand-alone zips is not sufficient verification.  For example, the eclipse executable is not within a JAR, and a compromised executable would negate the value of any other signing.  Possible approaches for signing stand-alone executables:

* Do nothing.  If users want to obtain verifiable content, they must obtain it from an update site
* Sign only the JARs within the stand-alone zip.  This has no authentication value in itself, but might be useful raw material for others in the community who want to tackle complete authentication of an Eclipse-based application
* Create a signature of the entire zip file, and make the signature available in a separate JAR file.  The user would then have to perform verification manually

==== Signing update site content ====

Signing of content on Eclipse update sites is slightly easier.  All executable content is contained in JAR files, so the traditional Java JAR signing mechanism can be used.

=== How is signing done? ===

There are several ways we could sign update JAR content:

* Traditional Java JAR signing.  The JDK comes with a tool called [http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jarsigner.html jarsigner]. This tool signs JARs by producing a separate signature for every file in the JAR.  The signatures are put in the MANIFEST.MF file and in a separate signature file in the META-INF directory.  For optimization purposes, the signature of the MANIFEST.MF with all embedded signatures is also computed and placed in the signature file.  The pros of using this approach are that the jarsigner tool is already available, and the signed JAR can also be used for runtime verification. The cons are that producing signatures for every file adds bulk to the download (about 3MB for the Eclipse SDK), and it is very slow to run (about an hour for the Eclipse SDK).
* Compute a single signature per JAR file.  This should be much faster and have negligible size, but would require a custom signing tool. The signature would be placed in a separate JAR signed using jarsigner (either one signature JAR per update JAR, or one signature JAR per update site).
* Nested JARs.  A sneaky way to get a single signature per JAR is to put each JAR in a wrapper JAR, and sign the wrapper.  This would allow using the jarsigner tool, but would require significant changes to the structure of update site content, and changes to the update code to remove the signed wrappers

''The main challenge in doing it the non-standard way is that the jars are not usable as signed by normal classloaders (e.g., when running with JNLP and the org.eclipse.osgi bundle which is loaded by a standard URL classloader)''

=== Where is signing done? ===

A critical part of the security behind signing is that the private keys used to produce the signatures are held in a secure location and never transmitted or accessible via a network. To accomplish this, the signing needs to be done on a secure machine that has access to the private key.  The Eclipse Foundation has set up a machine with a signing script.  The build will upload content to be signed to this machine, and a script is run to perform the signing.  Access to this machine will be given to trusted parties that want to perform signing.

=== When is signing done? ===

Signing will be done as part of the build process.  Because this adds a significant amount of time to the build process, the releng team is investigating streamlining the build process.  The process of producing a signed build is:

 # Checkout source from eclipse.org CVS repositories to build machine
 # Run build and produce build output
 # Send build output to eclipse.org for signing
 # Send signed build to download server, and to test machines for automated testing

Currently the Eclipse project build machine is located remote from the Eclipse Foundation servers.  This means the Eclipse source has to be transferred across the Internet, and the build output needs to be transferred back to Foundation machines for signing.  These two major network bottlenecks could be removed by also using Eclipse Foundation machines for building.

=== What public key (certificate) do we use? ===

The Eclipse Foundation should purchase a certificate from a secure certificate provider, such as verisign.  Content made available on Eclipse.org will be signed with the foundation certificate.  Note this doesn't preclude other parties from later signing the JARs with their own certificates.

=== Where are the signatures stored? ===

Using traditional JDK signing, the signatures are stored in the JAR file, both in the MANIFEST.MF, and in a separate signature file (currently Eclipse_.sf).

=== When does verification happen? ===

Verification can happen any time.  The common times to perform verification are:
* During update.  Minimally, verification happens at the time the client obtains the signed content.  The Eclipse update mechanism will perform verification of any update JARs that are signed, and will prompt the user for confirmation if the certificate used for signing is not trusted.  
* At load-time.  It is sometimes desirable to perform verification at load time when classes are loaded from a JAR.  The default Java class loader performs this verification automatically for any signed JAR on the classpath.  The Eclipse class loader can also be configured to perform load-time verification, but it is optional.
* Manual user verification.  The Eclipse about dialog will be augmented to show what plugins are signed.  From this dialog the user should be able to manually perform verification of signed content if desired.

== Miscellaneous links ==

* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=43889 OSGi Bundle signing bug report]
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=78208 Bug for runtime signing support]
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=94461 Bug for signing indicator in About dialog]
* [https://www.verisign.com/products-services/security-services/code-signing/digital-ids-code-signing/index.html Verisign code signing products]