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 "Californium/Signing Process"

m
Line 12: Line 12:
 
# GPG key is kept in the home directory of the genie account of the HIPP
 
# GPG key is kept in the home directory of the genie account of the HIPP
 
# All committers sign the GPG key with their (personal) keys
 
# All committers sign the GPG key with their (personal) keys
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml)
+
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml) on the HIPP
# HIPP polls Git repo to trigger Milestone and/or Release builds
+
# In order to create a Milestone and/or Release a committer tags the intended commit in GitHub accordingly and configures and (manually) triggers the release build in Hudson which checks out the particular version, builds the release, signs the artifacts using the project GPG key and uploads the artifacts to Maven Central's staging repo
 
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required
 
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required
  
 
== Using the Hudson Instance ==
 
== Using the Hudson Instance ==
  
The HIPP already supports GPG. It can poll the Git repository at a chosen rate and trigger Milestone and/or Release builds, which automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).
+
The HIPP already supports GPG. Release builds can be either triggered manually or whenever changes are committed to the Git repository. The build process can automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).
  
 
For this, we need to specify the '''Maven Central staging repo credentials (see open questions)''' and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).
 
For this, we need to specify the '''Maven Central staging repo credentials (see open questions)''' and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).
Line 24: Line 24:
 
== Key Creation ==
 
== Key Creation ==
  
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the keyring.
+
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the GPG key ring on the project's HIPP machine.
  
 
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.
 
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.
Line 39: Line 39:
 
The Hudson log shows what triggered the corresponding build (a SCM change or a user), and hence the release. The build is based on a Git commit, which in turn also has an author and committer.
 
The Hudson log shows what triggered the corresponding build (a SCM change or a user), and hence the release. The build is based on a Git commit, which in turn also has an author and committer.
  
This traceability assumes that the HIPP is not compromised, of course, and that no normal user can trigger custom release builds that use sources other than a traceable Git commit.
+
This tracability assumes that the HIPP is not compromised, of course, and that no normal user can trigger custom release builds that use sources other than a traceable Git commit.
  
 
== Open Questions ==
 
== Open Questions ==

Revision as of 11:21, 1 September 2015

This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here.


It is important for the project to distribute milestones and releases to Maven Central because most people will want to pull in their dependencies from there. This requires the builds to be signed using GPG, which is usually done using the private key of the committer who performs the release locally on his own machine.

The above process is problematic when within a company network. Furthermore, it is desirable to have a reproducible publishing process in place that can be triggered by any committer, always yielding the same result, i.e. independent from which person actually triggered the process. The Eclipse Foundation provides the facility to sign JAR files and also Windows and OS X applications with the Foundation's certificate. However, it does not provide any facility so far to GPG sign artifacts. Thus, we use the following signing process for the Californium project to distribute milestone and release builds through the HIPP:

Summary

  1. Eclipse webmaster creates the GPG key pair for signing on the HIPP using cf-dev@eclipse.org
  2. GPG key is kept in the home directory of the genie account of the HIPP
  3. All committers sign the GPG key with their (personal) keys
  4. Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml) on the HIPP
  5. In order to create a Milestone and/or Release a committer tags the intended commit in GitHub accordingly and configures and (manually) triggers the release build in Hudson which checks out the particular version, builds the release, signs the artifacts using the project GPG key and uploads the artifacts to Maven Central's staging repo
  6. To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required

Using the Hudson Instance

The HIPP already supports GPG. Release builds can be either triggered manually or whenever changes are committed to the Git repository. The build process can automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).

For this, we need to specify the Maven Central staging repo credentials (see open questions) and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).

Key Creation

The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the GPG key ring on the project's HIPP machine.

The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.

Californium committers sign this key with their (personal) keys in order to improve trustworthiness.

Key Invalidation

The key should expire after recommended time. If something goes wrong, a majority vote by the committers should be required to invalidate and/or replace the key through the webmaster.

Traceability

The Hudson log shows what triggered the corresponding build (a SCM change or a user), and hence the release. The build is based on a Git commit, which in turn also has an author and committer.

This tracability assumes that the HIPP is not compromised, of course, and that no normal user can trigger custom release builds that use sources other than a traceable Git commit.

Open Questions

  • Thanh Ha recommended that the trusted builds are built from trusted commits/tags, which are signed by a committer key. How do committers sign these?
  • Do we also need a project account for the oss.sonatype.org repo? I remember some automatic synchronization between this and the Eclipse repo for release builds...

Back to the top