Over at Linux.com, Yocto Project architect Richard Purdie writes about various kinds of problems that the project is experiencing, some of which stem from its success and growth. It is a story that will likely resonate with other open-source projects. Our scale also means patch requirements are more demanding now. Once, when the number of people using the project was small, the impact of breaking things was also more limited, allowing a little more freedom in development. Now, if we accept a change commit and something breaks, it becomes an instant emergency, and I’m generally expected to resolve it. When patches come from trusted sources, help will often be available to address the regressions as part of an unwritten bond between developers and maintainers. This can intimidate new contributors; they can also find our testing requirements too difficult.

We did have tooling to help new contributors—and also the maintainers—by spotting simple, easily detected errors in incoming patches. This service would test and then reply to patches on the mailing list with pointers on how to fix the patches, freeing maintainer time and helping newcomers. Sadly, such tools require maintenance, and we lost the people who knew how to look after this component, so it stopped working. We formed plans to bring it back and make the maintenance easier, but we’ve struggled to find anyone with the time to do it. I’ve wondered if I should personally try to do it; however, I just can’t spend the chunk of time needed on one thing like that, as I would neglect too many other things for too long.

If legacy networks are like individual homes with a few doors where a handful of people have the key, then cloud-based environments are like apartment complexes that offer both higher density and greater flexibility, but which include more key holders and potential entry points. The importance of protecting virtual machines (VMs) running in these environments — from both the host and other tenants — has become increasingly clear. The Linux Secure VM Service Module (SVSM) is a new, Rust-based, open-source project that aims to help preserve the confidentiality and integrity of VMs on AMD hardware.

Security updates have been issued by Debian (curl, dojo, git, lemonldap-ng, libapache-session-browseable-perl, libapache-session-ldap-perl, libzen, node-object-path, openjdk-11, sofia-sip, tiff, tor, and varnish), Fedora (libgit2, open62541, pgadmin4, rubygem-git, rust-bat, rust-cargo-c, rust-git-delta, rust-gitui, rust-libgit2-sys, rust-libgit2-sys0.12, rust-pore, rust-pretty-git-prompt, rust-rd-agent, rust-rd-hashd, rust-resctl-bench, rust-resctl-demo, rust-silver, and rust-tokei), Scientific Linux (thunderbird), SUSE (ffmpeg, krb5, nginx, python39-setuptools, sssd, systemd, tiff, and virtualbox), and Ubuntu (linux-azure, linux-azure-5.4, linux-raspi2, linux-azure-fde, and mysql-5.7, mysql-8.0).

The 6.2-rc6 kernel prepatch is out for testing.

It's suspiciously small, but who am I to look a gift horse in the mouth? I'll take it and hope it's not an aberration, but instead a sign that 6.2 is shaping up nicely. Call me optimistic, call me naive, but let's enjoy it and hope the trend continues.

The plan is still to do an -rc8, though, meaning that the final 6.2 release can be expected on February 19.

Version 1.67.0 of the Rust language has been released. The list of new features is relatively short; it includes support for #[must_use] on async functions and a new multi-producer, single-consumer channel implementation.

Memory allocation within the kernel is a complex business. The amount of physical memory available on any given system will be strictly limited, meaning that an allocation request can often only be satisfied by taking memory from somebody else, but some of the options for reclaiming memory may not be available when a request is made. Additionally, some allocation requests have requirements dictating where that memory can be placed or how quickly the allocation must be made. The kernel's memory-allocation functions have long supported a set of "GFP flags" used to describe the requirements of each specific request. Those flags will probably undergo some changes soon as the result of this patch set posted by Mel Gorman; that provides an opportunity to look at those flags in some detail.

Security updates have been issued by Debian (bind9, chromium, and modsecurity-apache), Fedora (libgit2, mediawiki, and redis), Oracle (go-toolset:ol8, java-1.8.0-openjdk, systemd, and thunderbird), Red Hat (java-1.8.0-openjdk and redhat-ds:12), SUSE (apache2, bluez, chromium, ffmpeg-4, glib2, haproxy, kernel, libXpm, podman, python-py, python-setuptools, samba, xen, xrdp, and xterm), and Ubuntu (samba).

The BPF subsystem exposes many aspects of the kernel's internal algorithms and data structures; this naturally leads to concerns about maintaining interface stability as the kernel changes. The longstanding position that BPF offers no interface-stability guarantees to user space has always seemed a little questionable; kernel developers have, in the past, found themselves having to maintain interfaces that were not intended to be stable. Now the BPF community is starting to think about what it might mean to provide explicit stability promises for at least some of its interfaces.

Paul McKenney looks at a couple of Rust crates in an attempt to determine whether they actually implement the read-copy-update algorithm; in the process, he gives an overview of the numerous RCU variants in the kernel.

Except that the first RCU crate, rcu_clean, throws a monkey wrench into the works. It does not have any grace-period primitives, but instead a clean() function that takes a reference to a RCU-protected data item. The user invokes this at some point in the code where it is known that there are no readers, either within this thread or anywhere else. In true Rust fashion, in some cases, the compiler is able to prove the presence or absence of readers and issue a diagnostic when needed.

Security updates have been issued by Debian (git), Fedora (libXpm and redis), Oracle (bind, firefox, grub2, java-1.8.0-openjdk, java-11-openjdk, kernel, libtasn1, libXpm, and sssd), Red Hat (thunderbird), SUSE (freeradius-server, kernel, libzypp-plugin-appdata, python-certifi, and xen), and Ubuntu (bind9, krb5, linux-raspi, linux-raspi-5.4, and privoxy).

The LWN.net Weekly Edition for January 26, 2023 is available.

While there are still systems with both byte orders, little-endian has largely "won" the battle at this point since the vast majority of today's systems store data with the least-significant byte first (at the lowest address). But when the X11 protocol was developed in the 1980s, there were lots of systems of each byte order, so the X protocol allowed either order and the server (display side) would swap the bytes to its byte order as needed. Over time, the code for swapping data in the messages, which was written in a more-trusting era, has bit-rotted so that it is now a largely untested attack surface that is nearly always unused. Peter Hutterer has been doing some work to stop using that code by default, both in upstream X.org code and in downstream Fedora.

The Free Software Foundation has announced a bylaw change requiring a 66% vote by the FSF board for any new or revised copyright licenses. The FSF has also announced an expansion of its board of directors and a call for nominations from among its associate members.

Kostya Shishkov has just posted the concluding installment of an extensive history of the FFmpeg project:

See, unlike many people I don’t regard FFmpeg as something unique (in the sense that it’s a project only Fabrice Bellard could create). It was nice to have around and it helped immeasurably but without it something else would fill the niche. There were other people working on similar tasks after all (does anybody remember transcode? or gmerlin?). Hopefully you got an idea on how many talented unsung heroes had been working on FFmpeg and libav over the years.

The full set can be found on this page. (Thanks to Paul Wise).

Users of the openSUSE Leap 15.3 distribution will want to be looking at moving on; support for that release has come to an end. "The currently maintained stable release is openSUSE Leap 15.4, which will be maintained until around end of 2023 (same lifetime as SLES 15 SP4 regular support)".

Security updates have been issued by Debian (libde265, nodejs, and swift), Fedora (nautilus), Oracle (bash, bind, curl, dbus, expat, firefox, go-toolset, golang, java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, libreoffice, libtiff, libxml2, libXpm, nodejs, nodejs-nodemon, postgresql-jdbc, qemu, ruby:2.5, sqlite, sssd, sudo, and usbguard), Red Hat (bind, go-toolset-1.18, go-toolset:rhel8, kernel, kernel-rt, kpatch-patch, pcs, sssd, and virt:rhel, virt-devel:rhel), Scientific Linux (bind, java-1.8.0-openjdk, kernel, and sssd), SUSE (mozilla-nss, rubygem-websocket-extensions, rust1.65, rust1.66, and samba), and Ubuntu (mysql-5.7, mysql-5.7, mysql-8.0, pam, and samba).

The Python community is currently struggling with a longtime difficulty in its ecosystem: how to develop, package, distribute, and maintain libraries and applications. The current situation is sub-optimal in several dimensions due, at least in part, to the existence of multiple, non-interoperable mechanisms and tools to handle some of those needs. Last week, we had an overview of Python packaging as a prelude to starting to dig into the discussions. In this installment, we start to look at the kinds of problems that exist—and the barriers to solving them.

Version 8.0 of the WINE Windows compatibility layer has been released. The headline feature appears to be the conversion to PE ("portable executable") modules:

After 4 years of work, the PE conversion is finally complete: all modules can be built in PE format. This is an important milestone on the road to supporting various features such as copy protection, 32-bit applications on 64-bit hosts, Windows debuggers, x86 applications on ARM, etc.

Other changes include WoW64 support (allowing 32-bit modules to call into 64-bit libraries), Print Processor support, improved Direct3D support, and more.

The Open Source Technology Improvement Fund has announced the completion of a security audit of the Git source.

For this portion of the research a total of 35 issues were discovered, including 2 critical severity findings and a high severity finding. Additionally, because of this research, a number of potentially catastrophic security bugs were discovered and resolved internally by the git security team.

See the full report for all the details.

The 6.1.8, 5.15.90, 5.10.165, 5.4.230, 4.19.271, and 4.14.304 stable kernel updates have all been released; each contains another set of important fixes.