Skip to main content
Jump to: navigation, search

Difference between revisions of "JAR Signing"

(Eclipse Bugzilla reports)
Line 78: Line 78:
! Done || Description
! Done || Description
| [ Don't resign bundles that have already been signed by cert]

Revision as of 00:05, 23 February 2008


Eclipse project builds after 3.3 M3 are now signed. Signing allows users to verify that the content they obtain from and subsequently execute does indeed come from that source. Signing in a nutshell works as follows:

  1. Eclipse builds produce content in various forms (zips, update JARS)
  2. The Eclipse Foundation produces a signature of the build content using its private key (signature = private key + content)
  3. User downloads build content and signatures from or from mirrors
  4. The Eclipse Foundation makes available a public key for verifying signatures
  5. User consults some trusted authority to verify that the public key does indeed belong to the Eclipse Foundation
  6. 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 can either be done manually or as part of an automated build process. The Eclipse project build scripts create signed builds using the following steps:

  1. Checkout source from CVS repositories to build machine
  2. Run build and produce a single ZIP of all plugins in update site form (all plugins in JARs)
  3. Send build output to for signing
  4. Copy zip of signed JARs back to the build machine
  5. Prepare compressed pack200.gz JARs to optimize update site
  6. Send signed and packed build to update site
  7. Package standalone zips for downloads page
  8. Copy standalone zips to test machines for automated testing

See Platform-releng-signedbuild for details on how the Eclipse release engineering scripts accomplish this.

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 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).

What effect does signing have on runtime behaviour?

There are some side-effects of signing that can impact runtime behaviour:

  1. Class loaders may perform verification when they encounter signed content. Since verification is potentially expensive, this can impact performance. In particular, URLClassLoader and any subclasses will always verify any JAR from which classes are loaded if they contain a signature. By contrast, the class loaders used by OSGi will not perform verification by default. Therefore this does not impact most typical Eclipse/OSGi code, but may affect code that uses custom class loaders. If you are using custom class loaders and JAR verification isn't important to you, you can use JarProcessor_Options to flag your JAR as not requiring signing.
  2. java.util.jar.JarFile will verify jars unless explicitly configured not to. The JarFile constructors have an optional boolean parameter to configure whether verification should be performed. The simple constructors, such as JarFile(File) and JarFile(String), will perform verification. This can have a performance impact when dealing with signed jars.
  3. Since signatures are stored in the manifest of a JAR file, any code that parses and otherwise manipulates JAR manifests can have a performance impact. For example, anyone calling java.util.JarFile#getManifest() will cause the entire manifest file to be parsed. Most clients reading manifest are only interested in the manifest's main attributes (Manifest#getMainAttributes()). If so, they can write their own parser that reads these attributes much more quickly. The main attributes are separated from the per-entry attributes by the first blank line. See the Jar file specification for details.

Should third party JARs be signed?

A signature on a JAR file simply allows a user who downloads content from to verify that the content they receive matches the content on the server. Therefore, it makes sense to sign all content made available on, including JAR files originally obtained from third parties. However, with third party JARs there are two additional considerations:

  1. You need to ensure that signing the JAR is permitted by the license of the third party content
  2. If the third party JAR makes use of custom class loaders, there may be performance implications to signing the JAR. See the section on the effect of signing on runtime behaviour for more details.


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

Eclipse Bugzilla reports

Done Description
Don't resign bundles that have already been signed by cert
OSGi Bundle signing bug report
Runtime signing support
Signing indicator in About dialog
Check.gif Purchasing signing certificates
Check.gif Signing script to signal completion
Check.gif Starting signing immediately after signing script is called
Check.gif Bug for installing Java 1.5 on signing server
Check.gif Bug for installing Improved signing/packing application on signing server
Check.gif Bug for using OSGi verification during update

Other signing links

Back to the top