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 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)
What gets signed?
By default, every JAR pushed to an update site will be signed. This includes JARs nested at arbitrary depth within other JARs. Some JARs may be excluded if there are technical or legal reasons why they cannot be signed. In standalone zip distribtions, all JARed plugins will be signed, and un-JARed plugins will not be signed.
How is signing done?
Signing is performed using the JDK's 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.
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 must 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 a single ZIP of all plugins in update site form (all plugins in JARs)
- Send build output to eclipse.org for signing
- Send signed build to update site
- Copy zip of signed JARs back to the build machine, and package standalone zips
- Copy standalone zips 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 has purchased a signing certificate from 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?
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.
=== Eclipse Bugzilla reports