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 "OHF"

(Difference between pages)
m
 
(Audit record repository)
 
Line 1: Line 1:
== Overview ==
+
=== About OHF ===
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:
+
This is the Eclipse Open Healthcare Framework (OHF) wiki. The OHF project addresses part of an need to improve the levels of interoperability between applications and systems within and across healthcare organizations – corporate and regions.
  
# Eclipse builds produce content in various forms (zips, update JARS)
+
=== Additional OHF sites ===
# The Eclipse Foundation produces a signature of the build content using its private key (signature = private key + content)
+
* [http://www.eclipse.org/ohf/ OHF Project Home Page]
# User downloads build content and signatures from eclipse.org or from mirrors
+
* [http://ohf-dev.blogspot.com/ OHF Committers 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
+
# Verification is performed on the user's machine (signature + public key = hash of content)
+
  
== Signing ==
+
=== Discussions ===
 +
* [[OHF using SCA]]
  
=== What gets signed? ===
+
== OHF Relationship Management (& Current Events etc) ==
  
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.
+
* [[OHF Relationship Management: Java]]
 +
* [[OHF Relationship Management: Eclipse]]
 +
* [[OHF Relationship Management: Open Source Healthcare initiatives]]
 +
* [[OHF Relationship Management: Standards Organisations]]
 +
* [[OHF Relationship Management: Corporates]]
  
=== How is signing done? ===
+
=== Public Healthcare Serveices ===
 +
This section contains a list of known public standard healthcare services.
  
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.
+
The listed services are actors on one of the [http://www.ihe.net IHE] profiles. OHF implements components that interacts with these services. The purpose of the list is to help developers test the plugins they develop, to validate full interoperability across vendors, and to validate comliance with the standard.
  
=== Where is signing done? ===
+
None of the listed services are part of Eclipse or Eclipse OHF.
 +
The services are publicly avaliable for demos and interoperability
 +
tests and they are not part of production environment.
  
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.
+
'''We welcome any service providor that have a public standard based healthcare service to contact us in order to add new services to the list'''
  
=== When is signing done? ===
+
====Audit record repository====
 
+
{| style="background-color:#ABCDEF;"
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:
+
|+Public Healthcare Services
 
+
# 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 [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? ===
+
 
+
The signatures are stored in the JAR file, both in the MANIFEST.MF, and in a separate signature file (currently Eclipse_.sf).
+
 
+
== 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
+
! Vendor !! Service URL !! BSD SYSLOG Port !! Reliable Syslog Port 
 
|-
 
|-
|
+
! IBM
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=43889 OSGi Bundle signing bug report]
+
| ibmod235.dal-ebis.ihost.com || 541 || N/A
|-
+
|
+
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=78208 Runtime signing support]
+
|-
+
|
+
| [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]
+
|-
+
|
+
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=132046 Signing script to signal completion]
+
|-
+
|
+
| [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]
+
|-
+
|
+
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=135044 Bug for installing Improved signing/packing application on signing server]
+
|-
+
|
+
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=130383 Bug for using OSGi verification during update]
+
 
|}
 
|}
  
=== Other signing links ===
+
== OHF Meetings ==
 
+
* [[Face to Face meeting at EclipseCon]]
* [https://www.verisign.com/products-services/security-services/code-signing/digital-ids-code-signing/index.html Verisign code signing products]
+
** [[Pictures from the meeting]]
* [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]
+

Revision as of 18:08, 4 May 2006

About OHF

This is the Eclipse Open Healthcare Framework (OHF) wiki. The OHF project addresses part of an need to improve the levels of interoperability between applications and systems within and across healthcare organizations – corporate and regions.

Additional OHF sites

Discussions

OHF Relationship Management (& Current Events etc)

Public Healthcare Serveices

This section contains a list of known public standard healthcare services.

The listed services are actors on one of the IHE profiles. OHF implements components that interacts with these services. The purpose of the list is to help developers test the plugins they develop, to validate full interoperability across vendors, and to validate comliance with the standard.

None of the listed services are part of Eclipse or Eclipse OHF. 
The services are publicly avaliable for demos and interoperability 
tests and they are not part of production environment.

We welcome any service providor that have a public standard based healthcare service to contact us in order to add new services to the list

Audit record repository

Public Healthcare Services
Vendor Service URL BSD SYSLOG Port Reliable Syslog Port
IBM ibmod235.dal-ebis.ihost.com 541 N/A

OHF Meetings

Back to the top