It is not often that you see a Fedora change proposal for a version of the distribution that will not be available for 18 months or so, but that is exactly what was recently posted to the mailing list. The change targets the C source code in the myriad of packages that the distribution ships; it would fix code that uses some ancient compatibility features that were removed by the C99 standard but are still supported by GCC. As might be guessed from the long runway proposed, there is quite a bit of work to do to get there.

Phylum has posted an article with a detailed look at a set of malicious packages discovered by an automated system they have developed.

Similar to this attacker’s previous attempts, this particular attack starts by copying existing popular libraries and simply injecting a malicious __import__ statement into an otherwise healthy codebase. The benefit this attacker gained from copying an existing legitimate package, is that because the PyPI landing page for the package is generated from the setup.py and the README.md, they immediately have a real looking landing page with mostly working links and the whole bit. Unless thoroughly inspected, a brief glance might lead one to believe this is also a legitimate package.

Security updates have been issued by Debian (ffmpeg and linux-5.10), Fedora (libksba, openssl, and php), Gentoo (openssl), Mageia (curl, gdk-pixbuf2.0, libksba, nbd, php, and virglrenderer), Red Hat (kernel, kernel-rt, libksba, and openssl), SUSE (gnome-desktop, hdf5, hsqldb, kernel, nodejs10, openssl-3, php7, podofo, python-Flask-Security, python-lxml, and xorg-x11-server), and Ubuntu (backport-iwlwifi-dkms, firefox, ntfs-3g, and openssl).

The 5.4.222, 4.19.263, and 4.14.297 stable kernel updates have been released. The first two contain a single patch for a Clang compilation error; 4.14.297, instead, has a number of fixes and speculative-execution mitigations.

At the recently concluded Netdev 0x16 conference, which was held both in Lisbon, Portugal and virtually, Stanford professor John Ousterhout gave his personal views on where networking in data centers needs to be headed. To solve the problems that he sees, he suggested some "fairly significant changes" to those environments, including leaving behind the venerable—ubiquitous—TCP transport protocol. While LWN was unable to attend the conference itself, due to scheduling and time-zone conflicts, we were able to view the video of Ousterhout's keynote talk to bring you this report.

The much-anticipated OpenSSL 3.0.7 release, which fixes some high-risk security problems, is available. The release notes list two vulnerabilities (CVE-2022-3786 and CVE-2022-3602) that have not yet been documented on the OpenSSL vulnerabilities page. LWN commenter mat2 has provided the relevant information, though. It is worth updating quickly, but many sites do not appear to be at immediate risk.

Update: the associated security advisory is now available.

Security updates have been issued by Debian (python3.7), Gentoo (android-tools, expat, firefox, libjxl, libxml2, pjproject, sqlite, thunderbird, and zlib), Oracle (compat-expat1), Slackware (php8 and vim), SUSE (kernel, libtasn1, podman, and pyenv), and Ubuntu (libtasn1-6).

Systemd version 252 has been released. As usual, the list of changes is long. It includes a new systemd-measure tool for the calculation of PCR values and a bunch of infrastructure to use the result for disk encryption:

Net effect: if you boot a properly prepared kernel, TPM-bound disk encryption now defaults to be locked to kernels which carry PCR signatures from the same key pair. Example: if a hypothetical distro FooOS prepares its UKIs like this, TPM-based disk encryption is now – by default – bound to only FooOS kernels, and encrypted volumes bound to the TPM cannot be unlocked on kernels from other sources.

There's a lot more; see the announcement for all of the details.

The Linux security module (LSM) mechanism was created as a result of the first Kernel Summit in 2001; it was designed to allow the development of multiple approaches to Linux security. That goal has been met; there are several security modules available with current kernels. The LSM subsystem was not designed, though, to allow multiple security modules to work together on the same system. Developers have been working to rectify that problem almost since the LSM subsystem was merged, but with limited success; some small security modules can be stacked on top of the "major" ones, but arbitrary stacking is not possible. Now, a full 20 years after security-module support went into the 2.5 development kernel series, it looks like a solution to the stacking problem may finally be getting closer.

Security updates have been issued by Debian (batik, chromium, expat, libxml2, ncurses, openvswitch, pysha3, python-django, thunderbird, and tomcat9), Fedora (cacti, cacti-spine, curl, mbedtls, mingw-expat, and xen), Gentoo (apptainer, bind, chromium, exif, freerdp, gdal, gitea, hiredis, jackson-databind, jhead, libgcrypt, libksba, libtirpc, lighttpd, net-snmp, nicotine+, open-vm-tools, openexr, rpm, schroot, shadow, sofia-sip, tiff, and xorg-server), Mageia (libreoffice), Oracle (expat), Red Hat (device-mapper-multipath), and SUSE (cacti, cacti-spine, chromium, exim, jhead, kernel, libmad, opera, and pdns-recursor).

Version 4.4 of the GNU make utility is out. There is a long list of changes and a fair number of potential compatibility issues; see the announcement text for all the details.

The 6.1-rc3 kernel prepatch is out for testing.

So while rc2 was just _way_ bigger than usual, rc3 is only a bit larger than an average rc3 release is. But it's still on the largish side. I hope that things start calming down, and we'll start seeing the size of these rc's shrink. Please?

The 5.10.151 kernel was released on October 28 with a small fix to the PAHOLE_FLAGS in the kernel build. October 29 saw the release of the 6.0.6, 5.15.76, and 5.4.221 stable kernels, each with the usual collection of important fixes throughout the tree.

Update: 5.10.152 has now also been released with another set of important fixes.

The Rust Types Team announces that the long-awaited generic associated types feature will be stable in Rust 1.65.

At its core, generic associated types allow you to have generics (type, lifetime, or const) on associated types. Note that this is really just rounding out the places where you can put generics: for example, you can already have generics on freestanding type aliases and on functions in traits. Now you can just have generics on type aliases in traits (which we just call associated types).

Linux distributions were, as a general rule, designed during an era when most software of interest was written in C; as a result, distributions are naturally able to efficiently package C applications and the libraries they depend on. Modern languages, though, tend to be built around their own package-management systems that are designed with different goals in mind. The result is that, for years, distributors have struggled to find the best ways to package and ship applications written in those languages. A recent discussion in the Fedora community on the packaging of Rust applications shows that the problems have not yet all been solved.

Security updates have been issued by Debian (expat, ruby-sinatra, and thunderbird), Fedora (glances), Mageia (cups, firefox, git, heimdal, http-parser, krb5-appl, minidlna, nginx, and thunderbird), Oracle (389-ds:1.4, device-mapper-multipath, firefox, mysql:8.0, postgresql:12, and thunderbird), SUSE (dbus-1, libconfuse0, libtasn1, openjpeg2, qemu, and thunderbird), and Ubuntu (dbus, linux-azure-fde, and tiff).

Fedora releases have traditionally happened later than their target date, though the project has done better on that score in recent years. Ben Cotton has announced in Fedora Magazine that the upcoming Fedora 37 release, initially planned for October 25, won't be happening until November 15. The immediate cause is an impending OpenSSL update which fixes a vulnerability described as "critical".

Ironically, Fedora’s openness means we can’t start preparing ahead of time. All of our build pipelines and artifacts are open. If we were to start building updates, this would disclose the vulnerability before the embargo lifts. As a result, we only know that OpenSSL considers this the highest level of severity and Red Hat’s Product Security team strongly recommended we wait for a fix before releasing Fedora Linux 37.

The practice of requiring copyright assignments for contributions to free-software projects has been in decline for years; the GNU Binutils project may be the latest domino to fall in that regard. The Linux kernel project, unlike some others, has always allowed contributors to retain their copyrights, resulting in a code base that has widely distributed ownership. In such a project, who owns the copyright to a given piece of code is not always obvious. Some developers (or their employers) are insistent about the placement of copyright notices in the code to document their ownership of parts of the kernel. A series of recent discussions within the Btrfs subsystem, though, has made it clear that there is no project-wide policy on when these notices are warranted — or even acceptable.

This Laravel News article digs into the many enhancements that have found their way into the PHP language in the last couple of years or so.

Lovely Enums, the savior of pointless database tables and floating constants across the codebases of the world. Enums have quickly become one of my favorite features of PHP 8.1 - I can now push my roles into Enums instead of keeping them in a table that never changes.

Mara Bos has written a lengthy blog post on whether the Rust language needs to be standardized. The answer is "no" — but she draws a distinction between a "standard" (maintained by some distant standards body) and a "specification".

While no official decision has been made yet, there does seem to be a general agreement that we should indeed work towards having and maintaining an official complete Rust specification from within the Rust project. It’s just a lot of work, so I’m afraid we won’t get there with just some enthusiastic volunteers, even if we can use the Ferrocene specification as a start. We’ll need support and funding from the Rust Foundation and interested companies.