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 pages "JAR Signing" and "CDT/Obsolete/whoswho"

(Difference between pages)
 
(Added Dave Daoust to page)
 
Line 1: Line 1:
== Overview ==
+
The following is the list of who's who in the CDT. For each person we list their status (Committer versus Contributor) and the areas they have interest in.
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)
+
| [mailto:dschaefer@qnx.com Doug Schaefer - QNX]
# User downloads build content and signatures from eclipse.org or from mirrors
+
| CDT Project Lead, Committer, CDT Core parser and related features. [http://cdtdoug.blogspot.com Read my blog.]
# 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
+
| [mailto:leo.treggiari@intel.com Leo Treggiari - Intel]
# Verification is performed on the user's machine (signature + public key = hash of content)
+
| Committer, CDT Managed Build System primarily, but also Standard Make and Core
 
+
|-
== Open problems ==
+
| [mailto:crecoskie@ti.com Chris Recoskie - Texas Instruments]
 
+
| Committer, CDT Managed Build System primarily, Debug second, and a little bit of everything for good measure
=== What gets signed? ===
+
|-
 
+
| [mailto:mikhailk@qnx.com Mikhail Khodjaiants - QNX]
The two principal outputs from the build process are update site JARs and stand-alone zips.
+
| Committer, CDT Debugger
 
+
|-
==== Signing stand-alone zips ====
+
| [mailto:mikhail.sennikovsky@intel.com Mikhail Sennikovsky - Intel]
 
+
| Committer, CDT Managed Build System primarily, also interested in Standard Make, Core and Debug
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:
+
|-
 
+
| [mailto:norbert.ploett@siemens.com Norbert Ploett - Siemens]
* Do nothing. If users want to obtain verifiable content, they must obtain it from an update site
+
| Committer, CDT content assist, Managed Build System, Debug
* 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
+
| [mailto:dave.daoust@windriver.com David Daoust - Wind River]
 
+
| Committer, Useability, Scalablity, CDT Core parser and related features
==== 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? ===
+
 
+
=== What public key (certificate) do we use? ===
+
 
+
=== Where are the signatures stored? ===
+
 
+
=== When does verification happen? ===
+
 
+
 
+
== Miscellaneous links ==
+
 
+
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=43889 Bundle signing bug report]
+
* [https://www.verisign.com/products-services/security-services/code-signing/digital-ids-code-signing/index.html Verisign code signing products]
+

Revision as of 10:40, 12 April 2006

The following is the list of who's who in the CDT. For each person we list their status (Committer versus Contributor) and the areas they have interest in.

Doug Schaefer - QNX CDT Project Lead, Committer, CDT Core parser and related features. Read my blog.
Leo Treggiari - Intel Committer, CDT Managed Build System primarily, but also Standard Make and Core
Chris Recoskie - Texas Instruments Committer, CDT Managed Build System primarily, Debug second, and a little bit of everything for good measure
Mikhail Khodjaiants - QNX Committer, CDT Debugger
Mikhail Sennikovsky - Intel Committer, CDT Managed Build System primarily, also interested in Standard Make, Core and Debug
Norbert Ploett - Siemens Committer, CDT content assist, Managed Build System, Debug
David Daoust - Wind River Committer, Useability, Scalablity, CDT Core parser and related features

Back to the top