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 project builds after 3.3 M3 are now signed. Signing allows 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)

# Eclipse builds produce content in various forms (zips, update JARS)

Line 18:

Line 18:

Signing is performed using the JDK's [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.

Signing is performed using the JDK's [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.

+

+

If you're an Eclipse.org project and you'd like to sign your bundles, please see this document: http://wiki.eclipse.org/IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F

=== Where is signing done? ===

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

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.

+

+

At the time of writing, persons who want to get jar signing privilege need to be committers, and apply for that privilege with the Webmaster. Project leads are required to authorize the request. Special permissions will be granted to the committer's UNIX login on the jar signing machine.

=== When is signing done? ===

=== 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:

+

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:

# Checkout source from eclipse.org CVS repositories to build machine

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

# 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 build output to eclipse.org for signing

−

# Send signed build to update site

+

# Copy zip of signed JARs back to the build machine

−

# Copy zip of signed JARs back to the build machine, and package standalone zips

+

# Prepare compressed pack200.gz JARs to optimize update site

+

# Send signed and packed build to update site

+

# Package standalone zips for downloads page

# Copy standalone zips to test machines for automated testing

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

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.

Line 43:

Line 51:

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

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:

+

+

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

+

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

+

# 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 [http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html 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 eclipse.org to verify that the content they receive matches the content on the server. Therefore, it makes sense to sign all content made available on eclipse.org, including JAR files originally obtained from third parties. However, with third party JARs there are two additional considerations:

+

# You need to ensure that signing the JAR is permitted by the license of the third party content

+

# If the third party JAR makes use of custom class loaders, there may be performance implications to signing the JAR. See the section on [[#What effect does signing have on runtime behaviour%3F|the effect of signing on runtime behaviour]] for more details.

+

+

=== Can the signing process fail? ===

+

+

Yes. One common way it can fail, even when every one has done every thing correctly, is that due to network or server problems the Eclipse process can not communicate with the Timestamping Authority process. When this, or other failures, happen, there is no easy way to detect it automatically, at the time of the failure (see {{bug|321795}}). Such failures might just miss one jar out of hundreds, or might cause a whole set of jars to go unsigned. So, the point is, build distributions should ALWAYS be checked to make sure all jars are signed as expected, before being the jars are distributed (especially for releases, but even milestones and weekly builds, if expected to be picked up by others). While release engineers can write scripts or Java code to automate the checking, in its simplest form, it can be done by simply calling 'jarsigner' with the -verify option, such as

+

+

${JAVA_HOME}/bin/jarsigner -verify ${pathAndNameOfJarFile}

+

+

This prints out a short message, such as "verified" or "No signature found in MANIFEST.MF" or similar.

Overview

Eclipse project builds after 3.3 M3 are now signed. Signing allows 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)

Signing

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.

At the time of writing, persons who want to get jar signing privilege need to be committers, and apply for that privilege with the Webmaster. Project leads are required to authorize the request. Special permissions will be granted to the committer's UNIX login on the jar signing machine.

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:

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)

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

What effect does signing have on runtime behaviour?

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

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.

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.

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 eclipse.org to verify that the content they receive matches the content on the server. Therefore, it makes sense to sign all content made available on eclipse.org, including JAR files originally obtained from third parties. However, with third party JARs there are two additional considerations:

You need to ensure that signing the JAR is permitted by the license of the third party content

Can the signing process fail?

Yes. One common way it can fail, even when every one has done every thing correctly, is that due to network or server problems the Eclipse process can not communicate with the Timestamping Authority process. When this, or other failures, happen, there is no easy way to detect it automatically, at the time of the failure (see bug 321795). Such failures might just miss one jar out of hundreds, or might cause a whole set of jars to go unsigned. So, the point is, build distributions should ALWAYS be checked to make sure all jars are signed as expected, before being the jars are distributed (especially for releases, but even milestones and weekly builds, if expected to be picked up by others). While release engineers can write scripts or Java code to automate the checking, in its simplest form, it can be done by simply calling 'jarsigner' with the -verify option, such as

${JAVA_HOME}/bin/jarsigner -verify ${pathAndNameOfJarFile}

This prints out a short message, such as "verified" or "No signature found in MANIFEST.MF" or similar.

Verification

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.