Skip to main content
Jump to: navigation, search

Californium/Signing Process

< Californium
Revision as of 10:48, 2 September 2015 by (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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:


  1. Eclipse webmaster creates the GPG key pair for signing on the HIPP using
  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. The project also has a Sonatype account that is associated with the genie account (?) to deploy to the staging repository
  5. Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml) on the HIPP
  6. In order to create a Milestone and/or Release a committer tags the intended commit in GitHub accordingly 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 deploys the artifacts to the Sonatype staging repository using the corresponding Maven plugin
  7. To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required (e.g., when the HIPP is suspected to be compromised)

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

Key Creation

The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project ( 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.


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.

If it is suspected that the any part of the HIPP instance or GPG key is compromised in any way, the project should revoke the key immediately (see below) and once the system has been stabilized, a request must be made for a new key (see Key Creation).

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 repo? I remember some automatic synchronization between this and the Eclipse repo for release builds...

Back to the top