GPG

Introduction to GPG

This page aims at documenting how the Eclipse Foundation will work on establishing a Web of Trust for allowing project leads to sign Eclipse artifacts using OpenPGP. GPG is the GNU implementation of the OpenPGP standard (RFC 4880). It allows to encrypt/decrypt documents as well as to sign them.

Several open source communities like Maven (Central), Debian, or Ubuntu rely on OpenPGP for signing artifacts and package repositories.

GPG in a nutshell

GPG is based on public-key cryptography. A public key is used to encrypt data, and a private key is used to decrypt it. A private key may also be used to digitally sign an electronic document (email, image, JAR file, ...), and anyone in possession of the associated public key will be able to validate the authenticity of this document.

CA vs. Web of Trust

In a typical Public-Key Infrastructures (PKI), a public key's authenticity ("does this key really belong to this user?") is checked by means of Certificate Authorities. A user's public key is signed by a Certificate Authority, and there usually is a chain of trust that leads all the way to a Root Certificate that is issued by one of the very few Root Certificate Authorities. The trustworthiness of a user's certificate lies in the chain of trust between the Root CA and all the intermediates.

In GnuPG, authentication depends on a so-called web-of-trust. All the participants to the Web of Trust issue their own self-signed certificates, and authenticity of such certificates is established by getting other participants to the Web of Trust to attest those certificates' validity after for example meeting in person. Once the Web of Trust contains enough individuals, and enough trust links between those individuals, then there is likely a chain of trust between any two individuals, and therefore it is easy to check for the authenticity of a given certificate. Now of course, the trustworthiness of a Web of trust is only as strong as the policies each individual follows to sign another person's key.

Installing GnuPG

GnuPG is a GPL licensed tool available on all the major platforms (Linux, Windows, MacOSX).

• For MacOSX users, GPG Suite is a very complete suite with a GUI and a CLI https://gpgtools.org/gpgsuite.html
• For Windows users, Gpg4win http://gpg4win.org/download.html
• For Linux users, "gnupg" package is most likely available from your regular package manager

Installing GnuPG gives access to all the tools needed to create or sign keys, manage your "keyring", sign and/or encrypt documents, etc. On some platforms, the GnuPG tool suite will also integrate with your email client to enable signing/encryption of your emails.

Creating your GPG keypair

The first step to be able to sign or encrypt artifacts, or to sign other people's keys, is obviously to create your own GPG key pair. A key pair is a combination of a public key (that other parties can use to encrypt documents addressed to you) and one (or several) private keys that allow to actually sign or decrypt documents.

In order to generate your key pair, you don't need more than the following command-line

gpg --gen-key

We recommend you adopt the following best practices:

• Use RSA/RSA algorithm
• Adopt a key-length of 4096 bits
• Avoid setting a "comment" field
• Set a reasonable expiration date (e.g. 5 years), providing a way to disable your key automatically should you lose access to it and have no revocation certificate
• Generate a revocation certificate that will allow you to revoke your key should you forget your passphrase or should the private key be compromised/lost.

More best practices in this article that you may want to read.

Securing your GPG keypair

It is utterly important that your protect your GPG private key. If someone gains access to it he will be able to decrypt messages addressed to you or to sign in your name. If you lose your private key or simply just forget the passphrase, you won't be able to sign anymore, nor to encrypt documents.

• Make sure that your passphrase is long enough, hard to guess, and includes characters from the whole range of printable characters on your keyboard: combination of upper/lower case characters, numbers, special characters...
• If you have generated a revocation certificate for your key, it should be stored with the same level of security as your private key, if not higher. You may want to print out a copy of the certificate in addition to exporting it on a removable disk, and store it in a different place than your master keypair.

Building a web of trust

In order for your key, hence your future signatures of electronic documents to be trustworthy, you need to build a reputation by getting your key signed by other people. In the context of Eclipse projects, EMO will have its own GPG key that will be used to sign the keys of Eclipse project leads. This way, not only will we establish a Web of Trust among "Eclipse people" (since it is likely – and encouraged! - that Eclipse project leads and community at large will want to sign each other's keys), but also establish a direct trust link between project leads and the EMO. Anyone interested in asserting that a given release of an Eclipse project has been performed under the auspices of the Eclipse Foundation will be able to do so by verifying the trustworthiness of the GPG key, and whether it has been signed by EMO.

Keysigning party

One of the easiest and most efficient way to grow a web of trust is to hold a keysigning party, where individuals meet in person, and establish trust links by verifying every key belong to its claimed owner.

Eclipse Foundation plans on holding a keysigning party during EclipseCon 2015, March 9-12 in Burlingame, CA, to seed the Eclipse Web of Trust by providing an opportunity for Eclipse community members to sign each other's keys. EMO will be represented and will sign the keys of Eclipse project leads. Details on the party will be published before EclipseCon.

Using GPG for Eclipse projects

GPG for Maven artifacts

The Eclipse Foundation already provides an infrastructure for signing JAR files, but for projects that want to distribute bits in the form of Maven artifacts (in particular on Maven Central), this isn't enough. A Maven artifact is not only a JAR file (or any source or binary content, for that matter), it is also a .pom file with some metadata. Thanks to the maven-gpg-plugin, one can easily sign the artifacts produced by a Maven project. As of today, there is no central infrastructure at Eclipse for doing GPG signing of Maven artifacts, so projects have to go through the process of signing locally, and then upload to Maven Central. The Tycho project has detailed the steps you should follow to do this.

GPG for Debian

Some Eclipse projects release Debian packages, so it is desirable that such artifacts are signed so as consumers can be sure the package actually originates from the Eclipse project, and hasn't been altered. The Debian community provides tools to help sign .deb packages and repositories, detailed in the sections below.

Packages

Some Eclipse projects produce Debian packages that are to be distributed as standalone packages (as opposed to a repository that can be consumed through aptitude). Signing such packages allows to ensure they can't be corrupted and tampered with, and allows consumer to get a high level of confidence that the package was build under the supervision of the Eclipse Foundation and the project's PMC.

If you are building Debian packages using jdeb (e.g. thanks to the Maven plugin), then you can automate the signing so as it is done at the same time the .deb artifacts are produced by your Maven build. See https://github.com/tcurdt/jdeb/blob/master/docs/maven.md

Repositories

If a project wants to not only distribute standalone packages but also a full-blown repository, then it is also desirable to sign the repository. The Debian wiki details the procedure to setup signed Debian repositories.

Anyone interested in consuming a signed Debian repository will check that the fingerprint of the key used to sign the repo corresponds to a trustworthy individual. If that is indeed the case, the GPG key should be added to the list of trusted keys in apt.

GPG for RPM

TBC