Signing a release version

Releases must be signed prior to release, but the procedure for how to sign releases hasn't been formalized so far. This document is a scratchboard to gather links and resources so that we can end up with a document with adequate info for the novice ReleaseManager, to be transcribed and put here.

This procedure has been formalized and well documented for httpd, available at http://httpd.apache.org/dev/release.html. Java based projects may find the commons release document useful.

Note that for some good commentary on how users can verify signatures (with some useful background), see http://httpd.apache.org/dev/verification.html


Important

Signing requires a private key. Private keys should not be stored on our public servers, baring some policy statement to the contrary.

Release Managers typically build and sign the release on their own secured systems, and then push them to the ASF infrastructure, where other Committers and the Community can check them prior to a release vote.


Some discussion about writing this page...

Not true. There are so many assumptions in this document that it is virtually unusable for other projects. Some examples:

Well, frankly I'd suggest that performing signing operations is mostly pointless unless you understand the basic ideas of cryptographic signatures, and that an RM should be capable of educating himself to the extent that he *is* aware of the issues.

If you're looking for a good place to start, http://www.gnupg.org/gph/en/manual.html defines the concepts quite nicely.

Understanding digital signatures and using the specific tools are two different things. For example, I know a fair amount about encryption, signatures, certs, CRLs, etc., because I work for an internet security company, and the product I work on uses these technologies extensively. However, as an individual user, I had not had to use the PGP or GnuPG tools until I recently needed to sign an Apache release. My purpose in suggesting a page such as this was to help people with the mechanics of signing a release, not to educate them on what cryptography is or why releases should be signed.

The value of this page is that it shows what a Release Manager needs to learn. Step-By-Step instructions have the fault that they seems to imply that so long as the steps are followed, everything will be okay. Whereas, they are best thought of as aide memoirs detailing the minimum actions that are required to cut a release.   

Why we need to sign releases

Signing releases assures users that the software package they just download has not been tampered with since it was built. Users can get the cryptographic signature .asc/.sig file with the release and use their own copy of PGP/GPG/whatever to 'Verify' the signature, which proves that the software package was not changed since it was signed. It is part of the ASF's duty to ensure that we take reasonable precautions that the software we deliver to users is good and has not been tampered with.

The ASF protects releases in two ways. Most users don't need to know who cut the release just that the release was not tampered it left apache. MD5 sums are ideally suited for this. Developers and the ASF also need to know that the distribution was cut by the offical release manager and that the release has not been tampered with since it was built. Digital signatures allow this to happen. That's why MD5 sums and signatures are needed for all releases. (use "openssl md5" or equivalent to generate an MD5 - i.e. openssl md5 filename > filename.md5)    (Can someone confirm where we state this policy officially? Also: I think we should restrict signing to only be committers, since the ASF has a specific relationship with committers via CLA, etc. -sc)

What you need to do

Tools you can use

PGP[pgp]

Free:

Commercial:

Signing files with PGP 8.0 Freeware

To sign a file with PGP 8.0, you need to run PGPmail, despite the fact that signing the release itself is not related to e-mail.

With PGPmail running, select the 'Sign' option, and then select the file(s) you want to sign. If you select multiple files, a separate detached signature file will be created for each file. When the Enter Passphrase dialog appears, make sure you select the correct signing key, and check the 'Detached Signature' and 'Text Output' checkboxes. Then enter your passphrase, and click OK. (Note that if you have already signed a file since starting PGPmail, your passphrase may be cached, so you will not need to enter it again.)

PGPmail will create a detached signature file for each selected file, in the same directory as the original files. The files are created with a .sig extension, so you will need to rename them to have a .asc extension, per Apache convention. (Note: many projects still use .sig, so either extension should be OK for now -sc)

NOTE: The above instructions may also work for the commercial version of PGP 8.0, but since I don't have that available, I can't check.

=== Step by Step for PGP 8.0 Windows ==

For PGP 8.0 Windows, you have to

Onetime setup

Signing ritual

Note that if PGPMail skips the dialog where you choose "Detached Signature" and so forth, clear its cache.

To learn more aobut PGP 8.0, see the bundled documentation, which is quite good.

Publish your key to the KEYS file

You need to publish just the public half of your PGP/GPG key so that users can download it to verify the signatures later. You must publish it to the KEYS file that should be checked into CVS - either in your subproject's area, or perhaps in a global KEYS file somewhere on Apache. You may also wish to publish it to public keyservers as well, although this is optional. Note that the ASF does not have a specific public keyserver. To publish your key to the KEYS file, just export the public half of your key into a plain text file, and then just copy and paste it into the KEYS file. You can optionally add a line above your key with your name on it, but this is not required. Be sure to check in the KEYS file before uploading the release!

Some public servers you might consider:

ldap://keyserver.pgp.com

x-hkp://the.earth.li

ldap://europe.keys.pgp.com:11370

http://pgpkeys.mit.edu x-hkp://pgp.mit.edu

are both on the pgp-keys network.


Using GPG

This does not replace the official documentation. It is simply a list of steps that work.

Create your key

Export your key, appending to the project's KEYS file

Signing files

Adjust the list as necessary.

Good luck! :-)


The Apache Web of Trust

If all possible, please get your key cross-signed with some people in the apache web-of-trust; see

    http://www.apache.org/~henkp/trust/apache.html 

Step by Step

{{{ EXPORT

SigningReleases (last edited 2009-09-20 23:48:14 by localhost)