Arthur Cohen has posted a detailed introduction to the gccrs project on the Rust Blog, seemingly with the goal of convincing the Rust community about the value of the project.

Likewise, many GCC plugins are used for increasing the safety of critical projects such as the Linux kernel, which has recently gained support for the Rust programming language. This makes gccrs a useful tool for analyzing unsafe Rust code, and more generally Rust code which has to interact with existing C code. We also want gccrs to be a useful tool for rustc itself by helping pan out the Rust specification effort with a unique viewpoint - that of a tool trying to replicate another's functionality, oftentimes through careful experimentation and source reading where the existing documentation did not go into enough detail.

(LWN last looked at gccrs in October).

Flexible arrays — arrays that are declared as the final member of a structure and which have a size determined at run time — have long drawn the attention of developers seeking to harden the kernel against buffer-overflow vulnerabilities. These arrays have reliably been a source of bugs, so anything that can be done to ensure that operations on them stay within bounds is a welcome improvement. While many improvements, including the recent counted-by work, have been made, one of the most difficult cases remains. Now, however, developers who are interested in using recent compiler bounds-checking features are trying to get a handle on struct sockaddr.

The LWN.net Weekly Edition for November 7, 2024 is available.

Man pages maintainer Alejandro Colomar announced in September that he was suspending his work due to a lack of support. He has now let it be known that funding has been found for the next year at least:

We've been talking for a couple of months, and we have already agreed to sign a contract through the LF [Linux Foundation], where a number of companies provide the funds for the contract. The contract will cover the next 12 months for the agreed amount, and we should sign it in the following days. Since I've already seen a draft of the contract, and it looks good, I've already started maintaining the project again, starting on Nov 1st.

After a couple of years of effort, the BPF instruction set architecture has been accepted as RFC 9669, giving it a standard outside of the in-kernel implementation. This message from David Vernet (who also contributed an article on the standardization process last year) describes the process and why it is important:

Though some vendors have already implemented BPF offloading capabilities without having a standardized ISA, others are not quite as risk tolerant. As Christoph [Hellwig] discussed at LSFMM 2022, certain NVMe vendors have expressed an interest in building BPF offloading capabilities for various use cases such as eXpress Resubmission Path (XRP), but they simply can't fund such a project without certain components of BPF being standardized. Hence, the effort to standardize BPF was born.

Security updates have been issued by AlmaLinux (firefox, openexr, and thunderbird), Fedora (llama-cpp and python-quart), Oracle (firefox, openexr, thunderbird, and xorg-x11-server and xorg-x11-server-Xwayland), SUSE (chromium, govulncheck-vulndb, openssl-1_1, python311, and python312), and Ubuntu (linux-azure, linux-bluefield, linux-azure, linux-gcp, linux-ibm, openjpeg2, and ruby3.0, ruby3.2, ruby3.3).

OpenWrt is, despite its relatively low profile, one of our community's most important distributions; it runs untold numbers of network routers and has served as the base on which a lot of network-oriented development (including the bufferbloat-reduction work) has been done. At the beginning of 2024, a few members of the project announced a plan to design and produce a router device specifically designed to run OpenWrt. This device, dubbed the "OpenWrt One", is now becoming available; the kind folks at the Software Freedom Conservancy were kind enough to ship one to LWN, where the desire to play with a new toy is never lacking.

The 6.12-rc6 kernel prepatch is out for testing. Linus says: "Another week, another rc. Nothing odd or special seems to be going on - this may be a bit on the bigger side for an rc6, but not hugely so, and nothing stands out."

OpenStreetMap tends to dominate the space for open mapping data, but it is not the only project working in this area. At the 2024 Open Source Summit Japan, Marc Prioleau presented the Overture Maps Foundation, which is building and distributing a set of worldwide maps under open licenses. Overture may have a similar goal to OpenStreetMap, but its approach and intended uses are significantly different.

The LWN.net Weekly Edition for October 31, 2024 is available.

A project called Flock has announced its existence. Flock is a fork of the Flutter user-interface toolkit project, motivated by frustration with the resources that Google is putting into Flutter.

We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. Flock will add important bug fixes, and popular community features, which the Flutter team either can't, or won't implement.

(LWN looked at Flutter in 2020).

Linus has released 6.12-rc5 for testing.

rc5 looks perfectly normal, and maybe even on the small side of normal. The diffstat looks nice and flat too, with the exception of the removal of the da8xx fbdev driver due to it having been replaced by the tilcdc driver. And I'm sure we're all thinking the same thing: "What lovely descriptive driver names we have".

Small objects can lead to large email threads. In this case, the GNU C Library (glibc) community has been having an extensive debate over the handling of zero-byte allocations. Specifically, what should happen when a program calls realloc() specifying a size of zero? This is, it seems, a topic about which some people, at least, have strong feelings.

The LWN.net Weekly Edition for October 24, 2024 is available.

Perhaps one of the more surprising changes in the 6.12-rc4 development kernel was the removal of several entries from the kernel's MAINTAINERS file. The patch performing the removal was sent (by Greg Kroah-Hartman) only to the patches@lists.linux.dev mailing list; the change was included in a char-misc drivers pull request with no particular mention.

The explanation for the removal is simply "various compliance requirements". Given that the developers involved all appear to be of Russian origin, it is not too hard to imagine what sort of compliance is involved here. There has, however, been no public posting of the policy that required the removal of these entries.

Update: Linus Torvalds has since publicly supported this action and said that it will not be reverted.

Update 2: James Bottomley has clarified the requirements:

If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file.

The 6.11.5, 6.6.58, 6.1.114, 5.15.169, and 5.10.228 stable kernels have all been released; each contains another set of important fixes.

Version 3.4.0 of the OpenSSL SSL/TLS library has been released. It adds a number of new encryption algorithms, support for "directly fetched composite signature algorithms such as RSA-SHA2-256", and more. See the release notes for details.

Security updates have been issued by Debian (ffmpeg, ghostscript, libsepol, openjdk-11, openjdk-17, perl, and python-sql), Oracle (389-ds-base, buildah, containernetworking-plugins, edk2, httpd, java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, java-21-openjdk, kernel, python-setuptools, skopeo, and webkit2gtk3), Red Hat (buildah), Slackware (openssl), SUSE (apache2, firefox, libopenssl-3-devel, podman, and python310-starlette), and Ubuntu (cups-browsed, firefox, libgsf, and linux-gke).

Sasha Levin has announced a new tree that is intended to perform continuous-integration tests of pull requests aimed at the mainline. The plan is for this tree to hold more finished work than sometimes ends up in linux-next; in a name that seems destined to create typographical confusion, it is called "linus-next".

The linus-next tree aims to provide a more stable and testable integration point compared to linux-next, addressing the runtime issues that make testing linux-next challenging and focusing on code that's about to be pulled by Linus.

Linus has released 6.12-rc4 for testing. "I'm not happy with how big this is - it's probably far from the biggest rc4 ever, but it _is_ the biggest rc4 we've had in the 6.x series at least in number of commits."