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"

(Created page with "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, in p...")
 
Line 1: Line 1:
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, in particular parts that are marked in bold.
+
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.
  
 
----
 
----
Line 37: Line 37:
 
== Open Questions ==
 
== 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?
+
- 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...

Revision as of 07:53, 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)
  5. HIPP polls Git repo to trigger Milestone and/or Release builds
  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. 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).

For this, we need to specify the Maven Central staging repo credentials 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 keyring.

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.

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