Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "JAR Signing"

 
(How is signing done?)
(44 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 
== Overview ==
 
== Overview ==
We are working towards signing Eclipse builds for the 3.2 Callisto releaseThe 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 signedSigning 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 9: Line 9:
 
# Verification is performed on the user's machine (signature + public key = hash of content)
 
# Verification is performed on the user's machine (signature + public key = hash of content)
  
== Open problems ==
+
== Signing ==
  
 
=== What gets signed? ===
 
=== What gets signed? ===
  
The two principal outputs from the build process are update site JARs and stand-alone zips.
+
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.
  
==== Signing stand-alone zips ====
+
=== How is signing done? ===
  
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 itNote 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:
+
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 JARThe 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.
  
* Do nothing.  If users want to obtain verifiable content, they must obtain it from an update site
+
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
* 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 ====
+
=== Where is signing done? ===
  
Signing of content on Eclipse update sites is slightly easierAll executable content is contained in JAR files, so the traditional Java JAR signing mechanism can be used.
+
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 scriptThe 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.
  
=== How is signing done? ===
+
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)
 +
# Send build output to eclipse.org for signing
 +
# Copy zip of signed JARs back to the build machine
 +
# 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
 +
 
 +
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? ===
 
=== What public key (certificate) do we use? ===
 +
 +
The Eclipse Foundation [https://bugs.eclipse.org/bugs/show_bug.cgi?id=130943 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? ===
 
=== 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 [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.
 +
 +
== Verification ==
  
 
=== When does verification happen? ===
 
=== 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 ==
 
== Miscellaneous links ==
  
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=43889 Bundle signing bug report]
+
=== Eclipse Bugzilla reports ===
* [https://www.verisign.com/products-services/security-services/code-signing/digital-ids-code-signing/index.html Verisign code signing products]
+
 
 +
{|
 +
|-
 +
! Done || Description
 +
|-
 +
|
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=174475 Don't resign bundles that have already been signed by eclipse.org cert]
 +
|-
 +
|
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=43889 OSGi Bundle signing bug report]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=78208 Runtime signing support]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=94461 Signing indicator in About dialog]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=130943 Purchasing signing certificates]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=132046 Signing script to signal completion]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=132048 Starting signing immediately after signing script is called]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=134264 Bug for installing Java 1.5 on signing server]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=135044 Bug for installing Improved signing/packing application on signing server]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=130383 Bug for using OSGi verification during update]
 +
|-
 +
| [[Image:check.gif]]
 +
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=263708 Bug for using Timestamp Authority in signatures]
 +
|}
 +
 
 +
=== Other signing links ===
 +
 
 +
* [[Pack200#Jar_Processor]] documents the JarProcessor tool that performs JAR signing
 +
* [[JarProcessor_Options]] documents the options available for configuring the behaviour of JarProcessor
 +
* [https://www.verisign.com/products-services/security-services/code-signing/digital-ids-code-signing/index.html Verisign code signing products]
 +
* [http://java.sun.com/j2se/1.5.0/docs/guide/security/time-of-signing.html Sun docs on timestamps in signatures]
 +
* [http://opentsa.org/ Web site of open source time stamp protocol implementation]
 +
* [http://www.digistamp.com/ Time stamping service]
 +
 
 +
[[Category:Equinox]]
 +
[[Category:Security|JAR Signing]]
 +
[[Category:Eclipse_Platform_Releng| ]]

Revision as of 15:10, 11 September 2012

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:

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

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.

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?

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:

  1. Checkout source from eclipse.org 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 eclipse.org 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 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:

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

  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.

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.

Miscellaneous links

Eclipse Bugzilla reports

Done Description
Don't resign bundles that have already been signed by eclipse.org cert
OSGi Bundle signing bug report
Check.gif Runtime signing support
Check.gif 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
Check.gif Bug for using Timestamp Authority in signatures

Other signing links

Back to the top