❌

ModalitΓ  di lettura

Linux.dev mailing list service

We are pleased to announce the availability of a new mailing list service running under the new lists.linux.dev domain. The goal of this deployment is to offer a subscription service that:

  • prioritizes mail delivery to public-inbox archives available via lore.kernel.org
  • conforms to DMARC requirements to ensure subscriber delivery
  • makes minimal changes to email headers and no changes to the message body content for the purposes of preserving patch attestation

If you would like to host a Linux development mailing list on this platform, please see further details on the subspace.kernel.org site.

Why another mailing list service?

Linux development started in 1991 and has been ongoing for the past 30 years at an ever-increasing pace. Many popular code collaboration platforms have risen throughout these three decades -- and while some of them are still around, many others have shut down and disappeared without offering any way to preserve the history of the projects they used to host.

Development via mailed-in patches remains the only widely used mechanism for code collaboration that does not rely on centralized infrastructure maintained by any single entity. The Linux developer community sees transparency, independence and decentralization as core guiding principles behind Linux development, so it has deliberately chosen to continue using email for all its past and ongoing collaboration efforts.

What about vger.kernel.org?

The infrastructure behind lists.linux.dev supports multiple domains, so all mailing lists hosted on vger.kernel.org will be carefully migrated to the same platform while preserving current addresses, subscribers, and list ids. The only thing that will noticeably change is the procedure to subscribe and unsubscribe from individual lists. As majordomo is no longer maintained, we will instead switch to using separate subscribe/unsusbscribe addresses per each list.

There are no firm ETAs for this migration, but if you are currently subscribed to any mailing list hosted on vger.kernel.org, you will receive a message when the migration date is approaching.

  •  

Git mirror available in Beijing

If you are a developer located around Beijing, or if your connection to Beijing is faster and more reliable than to locations outside of China, then you may benefit from the new git.kernel.org mirror kindly provided by Code Aurora Forum at https://kernel.source.codeaurora.cn/. This is a full mirror that is updated just as frequently as other git.kernel.org nodes (in fact, it is managed by the same team as the rest of kernel.org infrastructure, since CAF is part of Linux Foundation IT projects).

To start using the Beijing mirror, simply clone from that location or add a separate remote to your existing checkouts, e.g.:

git remote add beijing git://kernel.source.codeaurora.cn/pub/scm/.../linux.git
git fetch beijing master

You may also use http:// and https:// protocols if that makes it easier behind corporate firewalls.

  •  

Nitrokey digital tokens for kernel developers

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:

Nitrokey logo

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:

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.

  •  

FTP limited on mirrors.kernel.org

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.

  •  

Heartbleed statement

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.

  •  

Happy new year and good-bye bzip2

Good-bye bzip2

We started listing xz-compressed versions of kernel archives in all our announcements back in March 2013, and the time has come to complete the switch. Effective immediately, we will no longer be providing bzip2-compressed versions for new releases of the Linux kernel and other software. Any previously released .tar.bz2 archives will continue to be available without change, and we will also continue to provide gzip-compressed versions of all new releases for the foreseeable future.

So, from now on, all releases will be offered as both .tar.gz and .tar.xz, but not as .tar.bz2. We apologize if this interferes with any automated tools.

Happy new year!

Happy new year to all kernel.org users and visitors. The Linux Foundation and Linux Kernel Archives teams extend their warmest wishes to you all, and we hope that 2014 proves to be just as awesome (or awesomer) for the Linux kernel.

  •  

New frontend and googlesource.com

Montreal frontend

We have added another official frontend for serving the kernel content, courtesy of Vexxhost, Inc. There is now a total of three frontends, one in Palo Alto, California, one in Portland, Oregon, and one in Montreal, Quebec. This should allow for better geographic dispersion of official mirrors, as well as better fault tolerance.

Kernel.googlesource.com

We are happy to announce that kernel.googlesource.com is now relying on grokmirror manifest data to efficiently mirror git.kernel.org, which means that if accessing git.kernel.org is too high latency for you due to your geographical location (EMEA, APAC), kernel.googlesource.com should provide you with a fast local mirror that is at most 5 minutes behind official sources.

We extend our thanks to Google for making this available to all kernel hackers and enthusiasts worldwide.

TLS 1.2 and PFS

With the latest round of upgrades, we are now serving TLS 1.2 with PFS across all kernel.org sites, offering higher protection against eavesdropping.

  •