Linux Weekly News

Linux Mint 20.2 "Uma" was released in Cinnamon, MATE, and Xfce editions on July 8. This new version of the popular desktop-oriented distribution has several improvements, including changes to the Update Manager, a new "Sticky Notes" app, a bulk file-renaming tool, improved file search, and better memory management in Cinnamon. Mint 20.2 is a long-term support (LTS) release that will receive security updates until 2025.

The 4.4.280 stable kernel update is available; it contains a small set of fixes, mostly focused on the futex subsystem.

The Firefox 91 release is available. Changes include stronger tracking-cookie protection, use of HTTPS within anonymous windows whenever possible, and more.

Security updates have been issued by CentOS (flatpak and microcode_ctl), Debian (c-ares, lynx, openjdk-8, and tomcat9), Fedora (kernel), openSUSE (apache-commons-compress, aria2, djvulibre, fastjar, kernel, libvirt, linuxptp, mysql-connector-java, nodejs8, virtualbox, webkit2gtk3, and wireshark), Oracle (kernel, kernel-container, and microcode_ctl), Red Hat (glib2, kernel, kernel-rt, kpatch-patch, and rust-toolset-1.52 and rust-toolset-1.52-rust), Scientific Linux (microcode_ctl), SUSE (kernel), and Ubuntu (c-ares, gpsd, and perl).

Traditionally, in virtualized environments, the host is trusted by its guests, and must protect itself from potentially malicious guests. With initiatives like confidential computing, this rule is extended in the other direction: the guest no longer trusts the host. This change of paradigm requires adding boundary defenses in places where there have been none before. Recently, Andi Kleen submitted a patch set attempting to add the needed protections in virtio. The discussion that resulted from this patch set highlighted the need to secure virtio for a wider range of use cases.

Security updates have been issued by Debian (ansible and bluez), Fedora (curl, kernel, mod_auth_openidc, rust-rav1e, and webkit2gtk3), Mageia (kernel and kernel-linus), openSUSE (php7 and python-reportlab), Oracle (ruby:2.7), Red Hat (microcode_ctl), SUSE (fastjar, kvm, mariadb, php7, php72, php74, and python-Pillow), and Ubuntu (docker.io).

The fifth 5.14 prepatch is out for testing. "Things are looking perfectly normal. Size is nominal, diffstat looks pretty normal, and the changes are all in the usual places"

The 5.13.9, 5.10.57, 5.4.139, 4.19.202, 4.14.243, 4.9.279, and 4.4.279 stable kernel updates have been released. Each contains a small set of important fixes. Users of 4.4 should note that 4.4.280 is already in the review process; it is due on August 10.

The memfd_secret() system call has, in one form or another, been covered here since February 2020. In the beginning, it was a flag to memfd_create(), but its functionality was later moved to a separate system call. There have been many changes during this feature's development, but its core purpose remains the same: allow a user-space process to create a range of memory that is inaccessible to anybody else — kernel included. That memory can be used to store cryptographic keys or any other data that must not be exposed to others. This new system call was finally merged for the upcoming 5.14 release; what follows is a look at the form this call will take in the mainline kernel.

Security updates have been issued by Debian (tomcat8), Mageia (bluez, exiv2, fetchmail, libsndfile, nodejs, php-pear, python-pillow, and rabbitmq-server), openSUSE (apache-commons-compress, balsa, djvulibre, mariadb, mysql-connector-java, nodejs8, opera, and spice-vdagent), Red Hat (ruby:2.7), SUSE (apache-commons-compress, djvulibre, java-11-openjdk, libsndfile, mariadb, nodejs8, and spice-vdagent), and Ubuntu (docker.io).

The Android 12 beta release first appeared in May of this year. As is almost obligatory, this release features "the biggest design change in Android's history"; what's an Android release without requiring users to relearn everything? That historical event was not meant to include one change that many beta testers are noticing, though: a kernel regression that breaks a significant number of apps. This problem has just been fixed, but it makes a good example of why preventing regressions can be so hard and how the kernel project responds to them when they do happen.

Security updates have been issued by Debian (jetty9 and openexr), openSUSE (mariadb and virtualbox), Red Hat (go-toolset-1.15 and go-toolset-1.15-golang), SUSE (djvulibre and mariadb), and Ubuntu (opencryptoki).

The LWN.net Weekly Edition for August 5, 2021 is available.

The GPSD project provides a daemon for communicating with various GPS devices in order to retrieve the location information that those sensors provide. But the GPS satellites also provide highly accurate time information that GPSD can extract for use by Network Time Protocol (NTP) servers. A bug in the GPSD code will cause time to go backward in October, though, which may well cause some havoc if affected NTP servers do not get an update before then.

Stable kernels 5.13.8, 5.10.56, 5.4.138, 4.19.201, 4.14.242, 4.9.278, and 4.4.278 have been released. They all contain important fixes and users should upgrade.

Security updates have been issued by Debian (asterisk, libpam-tacplus, and wordpress), Fedora (buildah and podman), openSUSE (thunderbird and webkit2gtk3), Oracle (kernel and varnish:6), SUSE (kernel, kvm, and webkit2gtk3), and Ubuntu (libdbi-perl and php-pear).

Over on the Google Security Blog, Kees Cook describes his vision for approaches to assuring kernel security in a more collaborative way. He sees a number of areas where companies could work together to make it easier for everyone to use recent kernels rather than redundantly backporting fixes to older kernel versions. It will take more engineers working on things like testing and its infrastructure, security tool development, toolchain improvements for security, and boosting the number of kernel maintainers: Long-term Linux robustness depends on developers, but especially on effective kernel maintainers. Although there is effort in the industry to train new developers, this has been traditionally justified only by the "feature driven" jobs they can get. But focusing only on product timelines ultimately leads Linux into the Tragedy of the Commons. Expanding the number of maintainers can avoid it. Luckily the "pipeline" for new maintainers is straightforward.

Maintainers are built not only from their depth of knowledge of a subsystem's technology, but also from their experience with mentorship of other developers and code review. Training new reviewers must become the norm, motivated by making upstream review part of the job. Today's reviewers become tomorrow's maintainers. If each major kernel subsystem gained four more dedicated maintainers, we could double productivity.

Neovim 0.5, the fifth major version of the Neovim editor, which descends from the venerable vi editor by way of Vim, was released on July 2. This release is the culmination of almost two years of work, and it comes with some major features that aim to modernize the editing experience significantly. Highlights include native support for the Language Server Protocol (LSP), which enables advanced editing features for a wide variety of languages, improvements to its Lua APIs for configuration and plugins, and better syntax highlighting using Tree-sitter. Overall, the 0.5 release is a solid upgrade for the editor; the improvements should please the existing fan base and potentially draw in new users and contributors to the project.

Security updates have been issued by Arch Linux (chromium, nodejs, nodejs-lts-erbium, and nodejs-lts-fermium), Debian (pyxdg, shiro, and vlc), openSUSE (qemu), Oracle (lasso), Red Hat (glibc, lasso, rh-php73-php, rh-varnish6-varnish, and varnish:6), Scientific Linux (lasso), SUSE (dbus-1, lasso, python-Pillow, and qemu), and Ubuntu (exiv2, gnutls28, and qpdf).

On his blog, Colin Watson has a lengthy reflection on moving the code for Ubuntu's Launchpad software-collaboration web application from Python 2 to Python 3. He looks at some of the problem areas for upgrading, both in general and for Launchpad specifically, some pain points that were encountered, lessons learned, and the nine known regressions that reached the Launchpad production code during the process. I’m not going to defend the Python 3 migration process; it was pretty rough in a lot of ways. Nor am I going to spend much effort relitigating it here, as it's already been done to death elsewhere, and as I understand it the core Python developers have got the message loud and clear by now. At a bare minimum, a lot of valuable time was lost early in Python 3's lifetime hanging on to flag-day-type porting strategies that were impractical for large projects, when it should have been providing for "bilingual" strategies (code that runs in both Python 2 and 3 for a transitional period) which is where most libraries and most large migrations ended up in practice. For instance, the early advice to library maintainers to maintain two parallel versions or perhaps translate dynamically with 2to3 was entirely impractical in most non-trivial cases and wasn't what most people ended up doing, and yet the idea that 2to3 is all you need still floats around Stack Overflow and the like as a result. (These days, I would probably point people towards something more like Eevee's porting FAQ as somewhere to start.)