Linux kernel releases PGP signatures

All kernel releases are cryptographically signed using OpenPGP-compliant signatures. Everyone is strongly encouraged to verify the integrity of downloaded kernel releases by verifying the corresponding signatures.

Linux kernel releases and all other files distributed via kernel.org mirrors are no longer signed by one centrally issued key. You will need to rely on the PGP Web of Trust in order to verify the authenticity of downloaded archives.

Basic concepts

Every kernel release comes with a cryptographic signature from the person making the release. This cryptographic signature allows anyone to verify whether the files have been modified or otherwise tampered with since the developer created and signed them. The signing and verification process uses public-key cryptography and it is next to impossible to forge a PGP signature without first gaining access to the developer's private key. If this does happen, the developers will revoke the compromised key and will re-sign all their previously signed releases with the new key.

To learn more about the way PGP works, please consult Wikipedia.

Kernel.org web of trust

In order for this section to make sense, you should first familiarize yourself with the way PGP Web of Trust works. You can start by reading the Wikipedia article on the subject.

In a few words, PGP keys used by members of kernel.org are cross-signed by other members of kernel.org (and, frequently, by many other people). If you wanted to verify the validity of any key belonging to a member of kernel.org, you could review the list of signatures on their public key and then make a decision whether you trust that key or not. This article from the GnuPG manual is a good first step towards understanding how you can use PGP trust relationships to validate keys: Using trust to validate keys.

In order to become part of the kernel.org web of trust, you should locate kernel.org members in your geographical area, then verify and sign their keys. To locate members of kernel.org in your area, you can either use the Google Map created for this purpose, or send an email to the users@kernel.org mailing list, requesting key signing.

Once you have verified and signed a few keys, you can use the trust relationship established in the process to verify other keys used in the kernel.org web of trust.

Using GnuPG to verify kernel signatures

All software released via kernel.org has corresponding PGP signatures. It should not be possible to upload any files to the kernel.org mirrors without providing a trusted PGP signature to go along with them.

To better illustrate the verification process, let's use Linux 3.1.5 release as a walk-through example. First, use "wget" or "curl -O" to download the release and the corresponding signature:

$ wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.1.5.tar.xz
$ wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.1.5.tar.sign

You will notice that the signature is made against the uncompressed version of the archive. This is done so there is only one signature required for .gz, .bz2 and .xz compressed versions of the release. Start by uncompressing the archive, using unxz in our case:

$ unxz linux-3.1.5.tar.xz

Now verify the .tar archive against the signature:

$ gpg --verify linux-3.1.5.tar.sign

You can combine these steps into a one-liner:

$ xz -cd linux-3.1.5.tar.xz | gpg --verify linux-3.1.5.tar.sign -

The likely output will be:

gpg: Signature made Fri 09 Dec 2011 12:16:46 PM EST using RSA key ID 6092693E
gpg: Can't check signature: public key not found

You will need to first download the public key from the PGP keyserver in order to verify the signature. Look at the first line of the output and note the "key ID" listed, which in our example is 6092693E. Now download this key from the key servers:

$ gpg --recv-keys 6092693E
gpg: requesting key 6092693E from hkp server subkeys.pgp.net
gpg: key 6092693E: public key "Greg Kroah-Hartman
     (Linux kernel stable release signing key) <greg@kroah.com>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   3  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 1f, 0u
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Let's rerun "gpg --verify":

$ gpg --verify linux-3.1.5.tar.sign
gpg: Signature made Fri 09 Dec 2011 12:16:46 PM EST using RSA key ID 6092693E
gpg: Good signature from "Greg Kroah-Hartman
     (Linux kernel stable release signing key) <greg@kroah.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

Notice the WARNING: This key is not certified with a trusted signature! You will now need to verify that the key used to sign the archive really does belong to the owner (in our example, Greg Kroah-Hartman). There are several ways you can do this:

Use the Kernel.org web of trust. This will require that you first locate the members of kernel.org in your area and sign their keys. Short of meeting the actual owner of the PGP key in real life, this is your best option to verify the validity of a PGP key signature.
Review the list of signatures on the developer's key by using "gpg --list-sigs". Email as many people who have signed the key as possible, preferably at different organizations (or at least different domains). Ask them to confirm that they have signed the key in question. You should attach at best marginal trust to the responses you receive in this manner (if you receive any).

If at any time you see "BAD signature" output from "gpg --verify", please first check that your download is correct and that the downloaded file is not truncated or otherwise corrupted. If you repeatedly get the same "BAD signature" output, email ftpadmin@kernel.org immediately, so we can investigate the problem.

Kernel.org checksum autosigner and sha256sums.asc

We have a dedicated off-the-network system that connects directly to our central attached storage and calculates checksums for all uploaded software releases. The generated sha256sums.asc file is then signed with a PGP key generated for this purpose and that doesn't exist outside of that system.

These checksums are NOT intended to replace the web of trust. It is merely a way for someone to quickly verify whether contents on one of the many kernel.org mirrors match the contents on the master mirror. While you may use them to quickly verify whether what you have downloaded matches what we have on our central storage system, you should still use the GPG web of trust to verify whether the release tarball actually matches what the kernel developer published.

Kernel releases prior to September, 2011

Prior to September, 2011 all kernel releases were signed automatically by the same PGP key:

pub   1024D/517D0F0E 2000-10-10 [revoked: 2011-12-11]
      Key fingerprint = C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E
uid                  Linux Kernel Archives Verification Key <ftpadmin@kernel.org>

Due to the kernel.org systems compromise, this key has been retired and revoked. It will no longer be used to sign future releases and you should NOT use this key to verify the integrity of any archives. It is almost certain that this key has fallen into malicious hands.

All kernel releases that were previously signed with this key are being cross-checked and will be signed with another key, created specifically for this purpose. Once the process is completed, the new key information will be put on this page.

Revocation certificates

The following revocation certificates have been issued for keys used in the past to sign kernel.org software releases:

Key ID 0x517D0F0E

Key fingerprint:

pub   1024D/517D0F0E 2000-10-10 [revoked: 2011-12-11]
      Key fingerprint = C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E
uid                  Linux Kernel Archives Verification Key <ftpadmin@kernel.org>

Revocation certificate:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: A revocation certificate should follow

iIkEIBECAEkFAk7lL6xCHQJLZXkgd2FzIHVzZWQgdG8gYXV0b3NpZ25pbmc7IGF1
dG9zaWduaW5nIHNlcnZlciB3YXMgY29tcHJvbWlzZWQuAAoJEMhroGpRfQ8OS7EA
nikD5S7mmNM0QRX+H4BDxvdWzXWyAKCTuDGOdLoZs8gnl/G5UKVjX9mVkg==
=eL49
-----END PGP PUBLIC KEY BLOCK-----

Key ID 0x1E1A8782

Key fingerprint:

pub   1024D/1E1A8782 1999-10-05 [revoked: 2000-10-10]
      Key fingerprint = 9DB4 C3A4 EF2A 3111 9072  82F3 F2A5 75DC 1E1A 8782
uid                  Linux Kernel Archives Verification Key <ftpadmin@kernel.org>

Revocation certificate:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Comment: A revocation certificate should follow

iEYEIBECAAYFAjnisTIACgkQ8qV13B4ah4K3DgCfShKQe2kfz68OKu0WwEzgKkAE
vIQAn3Y8CTCRZ9QEIwsIs93F501VUtPs
=l5FV
-----END PGP PUBLIC KEY BLOCK-----

Key ID 0x514C5279

Key fingerprint:

pub   1024R/514C5279 1998-12-16 [revoked: 1999-10-05]
      Key fingerprint = 59 B1 5F 6F E3 13 4C 8B  33 E5 14 35 21 F1 D1 03
uid                  Linux Kernel Archives <ftpadmin@kernel.org>

Revocation certificate:

Basic concepts

Kernel.org web of trust

Using GnuPG to verify kernel signatures

Kernel.org checksum autosigner and sha256sums.asc

Kernel releases prior to September, 2011

Revocation certificates

Key ID 0x517D0F0E

Key ID 0x1E1A8782

Key ID 0x514C5279

Other resources

Social