The Linux Foundation IT team has been working to improve the code integrity of git repositories hosted at kernel.org by promoting the use of PGP-signed git tags and commits. Doing so allows anyone to easily verify that git repositories have not been altered or tampered with no matter from which worldwide mirror they may have been cloned. If the digital signature on your cloned repository matches the PGP key belonging to Linus Torvalds or any other maintainer, then you can be assured that what you have on your computer is the exact replica of the kernel code without any omissions or additions. To help promote the use of PGP signatures in Linux kernel development, we now offer a detailed guide within the kernel documentation tree: Kernel Maintainer PGP Guide 
Further, we are happy to announce a new special program sponsored by The Linux Foundation in partnership with Nitrokey -- the developer and manufacturer of smartcard-compatible digital tokens capable of storing private keys and performing PGP operations on-chip. Under this program, any developer who is listed as a maintainer in the MAINTAINERS file, or who has a kernel.org account can qualify for a free digital token to help improve the security of their PGP keys. The cost of the device, including any taxes, shipping and handling will be covered by The Linux Foundation. To participate in this program, please access the special store front on the Nitrokey website: Nitrokey Start for Kernel Developers Who qualifies for this program? To qualify for the program, you need to have an account at kernel.org or have your email address listed in the MAINTAINERS file (following the "M:" heading). If you do not currently qualify but think you should, the easiest course of action is to get yourself added to the MAINTAINERS file or to apply for an account at kernel.org. Which devices are available under this program? The program is limited to Nitrokey Start devices. There are several reasons why we picked this particular device among several available options. First of all, many Linux kernel developers have a strong preference not just for open-source software, but for open hardware as well. Nitrokey is one of the few companies selling GnuPG-compatible smartcard devices that provide both, since Nitrokey Start is based on Gnuk cryptographic token firmware developed by Free Software Initiative of Japan. It is also one of the few commercially available devices that offer native support for ECC keys, which are both faster computationally than large RSA keys and generate smaller digital signatures. With our push to use more code signing of git objects themselves, both the open nature of the device and its support for fast modern cryptography were key points in our evaluation. Additionally, Nitrokey devices (both Start and Pro models) are already used by open-source developers for cryptographic purposes and they are known to work well with Linux workstations. What is the benefit of digital smartcard tokens? With usual GnuPG operations, the private keys are stored in the home directory where they can be stolen by malware or exposed via other means, such as poorly secured backups. Furthermore, each time a GnuPG operation is performed, the keys are loaded into system memory and can be stolen from there using sufficiently advanced techniques (the likes of Meltdown and Spectre). A digital smartcard token like Nitrokey Start contains a cryptographic chip that is capable of storing private keys and performing crypto operations directly on the token itself. Because the key contents never leave the device, the operating system of the computer into which the token is plugged in is not able to retrieve the private keys themselves, therefore significantly limiting the ways in which the keys can be leaked or stolen. Questions or problems? If you qualify for the program, but encounter any difficulties purchasing the device, please contact Nitrokey at shop@nitrokey.com. For any questions about the program itself or with any other comments, please reach out to info@linuxfoundation.org...
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. 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 after 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 PGP keys used by members of kernel.org are cross-signed by other members of the Linux kernel development community (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. See the Wikipedia article on the subject of the Web of Trust. Using the Web Key Directory If the task of maintaining your own web of trust is too daunting to you, you can opt to shortcut this process by using the "Trust on First Use" (TOFU) approach and rely on the kernel.org Web Key Directory (WKD). To import keys belonging to many kernel developers, you can use the following command: $ gpg2 --locate-keys [username]@kernel.org For example, to import keys belonging to Linus Torvalds and Greg Kroah-Hartman, you would use: $ gpg2 --locate-keys torvalds@kernel.org gregkh@kernel.org This command will verify the TLS certificate presented by kernel.org before importing these keys into your keyring. Using GnuPG to verify kernel signatures All software released via kernel.org has detached PGP signatures you can use to verify the integrity of your downloads. To illustrate the verification process, let's use Linux 4.6.6 release as a walk-through example. First, use "curl" to download the release and the corresponding signature: $ curl -OL https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.xz $ curl -OL https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.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 and .xz compressed versions of the release. Start by uncompressing the archive, using unxz in our case: $ unxz linux-4.6.6.tar.xz Now verify the .tar archive against the signature: $ gpg2 --verify linux-4.6.6.tar.sign You can combine these steps into a one-liner: $ xz -cd linux-4.6.6.tar.xz | gpg2 --verify linux-4.6.6.tar.sign - It's possible that you get a "No public key error": gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT using RSA key ID 38DBBDC86092693E gpg: Can't check signature: No public key Please use the "gpg2 --locate-keys" command listed above to download the key for Greg Kroah-Hartman and Linus Torvalds and then try again: $ gpg2 --locate-keys torvalds@kernel.org gregkh@kernel.org $ gpg2 --verify linux-4.6.6.tar.sign gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT gpg: using RSA key 38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown] 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 To make the "WARNING" message go away you can indicate that you choose to trust that key using TOFU: $ gpg2 --tofu-policy good 38DBBDC86092693E $ gpg2 --trust-model tofu --verify linux-4.6.6.tar.sign gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT gpg: using RSA key 38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [full] gpg: gregkh@kernel.org: Verified 1 signature in the past 53 seconds. Encrypted 0 messages. Note that you may have to pass "--trust-model tofu" the first time you run the verify command, but it should not be necessary after that. The scripted version If you need to perform this task in an automated environment or simply prefer a more convenient tool, you can use the following helper script to properly download and verify Linux kernel tarballs: get-verified-tarball Please review the script before adopting it for your needs. Important fingerprints Here are key fingerprints for Linus Torvalds, Greg Kroah-Hartman, Sasha Levin, and Ben Hutchings, who are most likely to be releasing kernels: Developer Fingerprint Linus Torvalds ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886 Greg Kroah-Hartman 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E Sasha Levin E27E 5D8A 3403 A2EF 6687 3BBC DEA6 6FF7 9777 2CDC Ben Hutchings AC2B 29BD 34A6 AFDD B3F6 8F35 E7BF C8EC 9586 1109 Please verify the TLS certificate for this site in your browser before trusting the above information. If you get "BAD signature" If at any time you see "BAD signature" output from "gpg2 --verify", please first check the following first: Make sure that you are verifying the signature against the .tar version of the archive, not the compressed (.tar.xz) version. Make sure the the downloaded file is correct and not truncated or otherwise corrupted. If you repeatedly get the same "BAD signature" output, please email helpdesk@kernel.org, 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 developer signatures. 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 continue to use developer signatures for best assurance. 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 were cross-checked and signed with another key, created specifically for this purpose: pub 3072R/C4790F9D 2013-08-08 Key fingerprint = BFA7 DD3E 0D42 1C9D B6AB 6527 0D3B 3537 C479 0F9D uid Linux Kernel Archives Verification Key (One-off resigning of old releases) <ftpadmin@kernel.org> The private key used for this purpose has been destroyed and cannot be used to sign any releases produced after 2011...
As you may be aware, starting with 4.12-rc1 Linus will no longer provide signed tarballs and patches for pre-release ("-rc") kernels. Reasons for this are multiple, but largely this is because people who are most interested in pre-release tags -- kernel developers -- do not rely on patches and tarballs to do their work. Obtaining tarballs on your own Here is how you can generate the tarball from a pre-release tag using the "git archive" command (we'll use 4.12-rc1 in these examples): git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git verify-tag v4.12-rc1 git archive --format=tar.gz --prefix=linux-4.12-rc1/ \ -o linux-4.12-rc1.tar.gz v4.12-rc1 The upside of this method is that during the "git verify-tag" step you will check the PGP signature on the tag to make sure that what you cloned is exactly the same tree as on Linus Torvalds's computer. The downside of this method is that you will need to download about 1 GiB of data -- the entire git history of the Linux kernel -- just to get the latest tag. Notably, when -rc2 is tagged, all you'll need to do is run a quick "git pull" to get the latest objects and it will be dramatically less data to download, so cloning the whole tree may be worth it to you in the long run if you plan to do this again in the future. If you do not want to download the whole git repository and just want to get the latest tarball, you can download the version automatically generated by cgit at the following (or similar URL): wget https://git.kernel.org/torvalds/t/linux-4.12-rc1.tar.gz Please note that you will not be able to cryptographically verify the integrity of this archive, but the download will be about 10 times less in size than the full git tree. Obtaining patches to the previous mainline If you would like to get just the patch to the previous mainline release, you can get it from cgit as well: wget -O patch-4.12-rc1 https://git.kernel.org/torvalds/p/v4.12-rc1/v4.11 Unfortunately, cgit does not currently offer an easy way to get gzip-compressed patches, but if you would like to reduce the amount of data you download, you can use http-level gzip compression: wget -O patch-4.12-rc1.gz --header="accept-encoding: gzip" \ https://git.kernel.org/torvalds/p/v4.12-rc1/v4.11 The links to these patches are available on the front page of https://www.kernel.org/. Why not provide these at their old locations? We intentionally did not provide these automatically generated tarballs and patches in locations previously used by Linus (/pub/linux/kernel/v4.x/testing), even if this meant potentially breaking automated scripts relying on contents published there. Anything placed in the /pub tree is signed and curated directly by developers and all patches and software archives published there invariably come with a PGP signature provided directly by the developer of that software (or one of the developers). Patches and tarballs automatically generated by git.kernel.org are NOT a replacement for this stringent process, but merely a convenience service that comes with very different trust implications. By providing these at different URLs we wanted all users of these services to make a conscious decision on whether they want to trust these automatically generated tarballs and patches, or whether they want to change their process to continue to use PGP-verifiable tags directly from the git tree...
The XZ tarballs for the following kernel releases did not initially pass signature verification due to benign changes to the tarball structure done by the pixz compression tool: 4.11.1 4.10.16 4.9.28 4.4.68 These changes would have resulted in GPG returning "Bad Signature" if you tried to verify their integrity. Once we identified the problem, we generated new XZ tarballs without tar header modifications and now they should all pass PGP signature verification. We preserved the original .xz tarballs as -badsig files in the archives in case you wanted to verify that there was nothing malicious in them, merely tar header changes. You can find them in the same v4.x directory: https://www.kernel.org/pub/linux/kernel/v4.x/ Our apologies for this problem and thanks to Brad Spengler and everyone else who alerted us about this issue...
We are extremely happy to announce that Packet has graciously donated the new hardware systems providing read-only public access to the kernel.org git repositories and the public website (git.kernel.org and www.kernel.org, respectively). We have avoided using cloud providers in the past due to security implications of sharing hypervisor memory with external parties, but Packet's hardware-based single-tenant approach satisfies our security requirements while taking over the burden of setting up and managing the physical hardware in multiple worldwide datacenters. As of March 11, 2017, the four new public frontends are located in the following geographical locations: San Jose, California, USA Parsippany, New Jersey, USA Amsterdam, Netherlands Tokyo, Japan We have changed our DNS configuration to support GeoDNS, so your requests should be routed to the frontend nearest to you. Each Packet-hosted system is significantly more powerful than our previous generation frontends and have triple the amount of available RAM, so they should be a lot more responsive even when a lot of people are cloning linux.git simultaneously. Our special thanks to the following organizations who have graciously donated hosting for the previous incarnation of kernel.org frontends: Internet Systems Consortium Vexxhost Tizen If you notice any problems with the new systems, please email helpdesk@kernel.org...
Those of you who have been around for a while may remember a time when you used to be able to mount kernel.org directly as a partition on your system using NFS (or even SMB/CIFS). The Wayback Machine shows that this was still advertised some time in January 1998, but was removed by the time the December 1998 copy was made. Let's face it -- while kinda neat and convenient, offering a public NFS/CIFS server was a Pretty Bad Idea, not only because both these protocols are pretty terrible over high latency connections, but also because of important security implications. Well, 19 years later we're thinking it's time to terminate another service that has important protocol and security implications -- our FTP servers. Our decision is driven by the following considerations: The protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons FTP servers have no support for caching or accelerators, which has significant performance impacts Most software implementations have stagnated and see infrequent updates All kernel.org FTP services will be shut down by the end of this year. In hopes to minimise the potential disruption, we will be doing it in two stages: ftp://ftp.kernel.org/ service will be terminated on March 1, 2017 ftp://mirrors.kernel.org/ service will be terminated on December 1, 2017 If you have any concerns, please feel free to contact ftpadmin@kernel.org (ah, the irony)...
If your browser alerted you that the site certificates have changed, that would be because we replaced our StartCOM, Ltd certificates with those offered by our DNS registrar, Gandi. We are very thankful to Gandi for this opportunity. A common question is why we aren't using the certificates offered by the Let's Encrypt project, and the answer is that there are several technical hurdles (on our end) that currently make it complicated. Once we resolve them, we will most likely switch to using certificates issued by our fellow Linux Foundation project...
If you find yourself on an unreliable Internet connection and need to perform a fresh clone of Linux.git, you may find it tricky to do so if your connection resets before you are able to complete the clone. There is currently no way to resume a git clone using git, but there is a neat trick you can use instead of cloning directly -- using git bundle files. Here is how you would do it. Start with "wget -c", which tells wget to continue interrupted downloads. If your connection resets, just rerun the same command while in the same directory, and it will pick up where it left off: wget -c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle Next, clone from the bundle: git clone clone.bundle linux Now, point the origin to the live git repository and get the latest changes: cd linux git remote remove origin git remote add origin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git pull origin master Once this is done, you can delete the "clone.bundle" file, unless you think you will need to perform a fresh clone again in the future. The "clone.bundle" files are generated weekly on Sunday, so they should contain most objects you need, even during kernel merge windows when there are lots of changes committed daily...
We are happy to announce that Fastly has offered their worldwide CDN network to provide fast download services for Linux kernel releases, which should improve download speeds for those of you located outside North America. We have modified the front page to offer CDN-powered download links, but all the existing URLs should continue to work. If you would like to avoid using Fastly, you can simply change the URL to have "www.kernel.org" instead of "cdn.kernel.org". As always, please use PGP Signature Verification for all downloaded files regardless of where you got them...
Linus named the upcoming 4.0 release of the kernel "Hurr Durr I'ma Sheep" (see his git commit), so we are celebrating this April Fool's day with a minor prank. If you've been redirected to imasheep.hurrdurr.org, do not panic. It's all part of the joke. We've also restored all FTP and Rsync access to the mirrors.kernel.org servers, as we seem to have resolved our SSD and dm_cache problems. If you're still using FTP, however, please consider switching to HTTP. FTP is a protocol designed for a different era -- these days everyone should be avoiding it for multiple reasons...
We've had to temporarily limit FTP access to mirrors.kernel.org due to high IO load. We have recently upgraded our hardware in order to increase capacity -- 16TB was no longer nearly sufficient enough to host all the distro mirrors and archives. We chose larger but slower disks and offset the loss of performance by heavily utilizing SSD IO caching using dm-cache. While it was performing very well, we have unfortunately run across an FS data corruption bug somewhere along this stack: megaraid_sas + dm_cache + libvirt/virtio + xfs We've temporarily removed dm-cache from the picture and switched to Varnish on top of SSD for http object caching. Unfortunately, as Varnish does not support FTP, we had to restrict FTP protocol to a limited number of concurrent sessions in order to reduce disk IO. If you are affected by this, simply switch to HTTP protocol that does not have such restrictions. This is a temporary measure until we identify the dm-cache problem that was causing data corruption, at which point we will restore unrestricted FTP access...
Since we rely on the OpenSSL library for serving most of our websites, we, together with most of the rest of the open-source world, were vulnerable to the HeartBleed vulnerability. We have switched to the patched version of OpenSSL within hours of it becoming available, plus have performed the following steps to mitigate any sensitive information leaked via malicious SSL heartbeat requests: Replaced all SSL keys across all kernel.org sites. Expired all active sessions on Bugzilla, Patchwork, and Mediawiki sites, requiring everyone to re-login. Changed all passwords used for admin-level access to the above sites. As kernel.org developers do not rely on SSL to access git repositories, there is no need to replace any SSH or PGP keys used for developer authentication. If you have any questions or concerns, please email us at webmaster@kernel.org for more information...