Brief items
Security
Julien Malka proposes method for detecting XZ-like backdoors
Julien Malka has called for the NixOS project to use build-reproducibility to detect when a program has a maintainer-generated tarball that results in a different artifact than building from source. There are good reasons for projects to release maintainer-generated tarballs, but since the materials included in them are usually documentation, extra build scripts, and so on, it makes sense to check that they don't influence the final build output. While this would not have stopped last year's XZ backdoor, it would have made it harder to hide.
People are often convinced that OSS is more trustworthy than closed-source software because the code can be audited by practitioners and security professionals in order to detect vulnerabilities or backdoors. In this instance, this procedure has been made difficult by the fact that part of the code activating the backdoor was not included in the sources available within the git repository but was instead present in the maintainer-provided tarball. While this was used to hide the backdoor out of sight of most investigating eyes, this is also an opportunity for us to improve our software supply chain security processes.
Security quotes of the week
The failure mode that creates security treadmills is a failure to implement "secure by design" principles. The legacy of computing that we've all inherited is one built in the high-trust environment of collaborating universities in the 70's and 80's, where tools and protocols were not designed with security as a major factor. We have to shake off this mindset as we build new tools and protocols.
For example, the ability for nearly every application to have full, unfettered access to the entire Internet is a deeply-held and rarely-challenged assumption. Cryptocurrencies generally cannot be mined without a constant internet connection since you need to receive information about the latest "blocks". Denying all outbound network traffic except for a few allow-listed hosts would be one non-treadmill solution, with the added bonus of thwarting exfiltration attacks, 2-stage malware attacks, and command-and-control servers.
The stats we collect for the #SpamAssassin project (mass-scan results from participating sites) have long shown that spammers are more consistent at making SPF, DKIM, and DMARC correct than are legitimate senders. DMARC in particular has no discernible benefit for most senders, so it is a useless signal.Rejecting mail based solely on authentication failures of those deeply flawed authentication methods does more harm than good.
— Bill Cole (Thanks to Paul Wise.)
Kernel development
Kernel release status
The 6.14 kernel is out; its release on March 24 was a bit later than expected:
So it's early Monday morning (well - early for me, I'm not really a morning person), and I'd love to have some good excuse for why I didn't do the 6.14 release yesterday on my regular Sunday afternoon release schedule.I'd like to say that some important last-minute thing came up and delayed things.
But no. It's just pure incompetence.
See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.14 page for details on what's new in this release.
Stable updates: 6.13.8, 6.12.20, and 6.6.84 were released on March 22.
The 6.13.9, 6.12.21, 6.6.85, and 6.1.132 updates are in the review process; they are due on March 27.
Quote of the week
Too many file systems bitrot in the kernel, and the actively maintained ones are large and complicated beasts. My ideal future is all file systems are moved out of the kernel and into FUSE or some other user-space file system mechanism. We have io-uring for fast access to disks, there's not really much of a performance benefit to being in the kernel anymore.— Josef Bacik
Distributions
An Asahi Linux 6.14 progress report
The Asahi Linux project, working to support Linux on Apple hardware, has published a progress report to coincide with the 6.14 kernel release.
Now that Rust for Linux abstractions are starting to be merged at a healthy pace, we are faced with an emerging challenge. It is rare for any kernel patch to survive the mailing list without at least a couple of non-trivial changes, and Rust abstractions are no exception. Every time an abstraction used by our driver is merged, we must drop our downstream version and rebase the driver atop the version accepted upstream. This is grueling, menial, and unpleasant work, and Janne has our deepest gratitude for volunteering his time to get through it.
Debian bookworm live images now fully reproducible
In a short note to the Reproducible Builds mailing list, Debian developer Roland Clobus announced that live images for Debian 12.10 ("bookworm") are now 100% reproducible. See the reproducible live images and Debian Live todo pages on the Debian wiki for more information on the images.
Introducing rpi-image-gen for customized Raspberry Pi images
Raspberry Pi has announced rpi-image-gen, a tool to create custom software images for its devices.
rpi-image-gen is a Bash orientated scripting engine capable of producing software images with different on-disk partition layouts, file systems and profiles using collections of metadata and a defined flow of execution. It provides the means to create a highly customised software image for your Raspberry Pi device. rpi-image-gen is human readable, auditable and easy to use.
The Git repository for rpi-image-gen has a number of examples to help users get started making their own custom images.
Distributions quotes of the week
I want to consider a different benefit to Ubuntu of doing the work to enable switching to a Rust implementation of coreutils: that the process of doing so will inevitably uncover, and require resolving, innumerable blockers to using Rust for core parts of the distribution. And that the work of doing so will pave the way for using Rust for other pieces of the distribution that do benefit from Rust's memory safety.
This was our experience with pyca/cryptography, where the initial release we did with Rust code did not benefit from Rust at all (it was a no-op module to test the build infrastructure). Shipping it, however, flushed out considerable technical and social challenges, everything from clearer error messages and instructions for how to install Rust to the need for a standard for distributing Python binaries for systems that use musl as their libc. Having done that work, we were able to a) use Rust for significantly more of our library where we did benefit considerably from both the security and performance benefits (e.g., replace OpenSSL's X.509 parsing with our own, netting a 10x speed-up), b) make it dramatically easier for other Python projects to adopt Rust. So even though our initial release did nothing to showcase Rust's benefits, it set the stage for big wins down the line.
If Canonical's adoption of a Rust coreutils can play the same role, of identifying and resolving the blockers that make it difficult to ship Rust at the core of a distribution, that will be incredibly valuable, and enable Rust to be used in the places that it really shines.
I wish folk in Free Software would try and be mindful of the incompatible changes they might introducing, and the toil they create for other volunteer developers, often not directly visible to the person making the change. The approach done by the Debian toolchain maintainers strikes me as a good balance; they do a bunch of work up front to try and flag all the places that might need to make changes, far enough in advance of the breaking change actually landing. However they don’t then allow a tardy developer to block progress.
Development
Neovim 0.11 released
Version 0.11 of the Neovim text editor has been released. Notable changes in this release include simpler Language Server Protocol (LSP) client setup, improved tree-sitter performance, better emoji support, and enhancements for Neovim's embedded terminal emulator. See the release notes for a full list of changes.
Bhattcharya: Closing the chapter on OpenH264
Boudhayan Bhattcharya has posted a lengthy article about the announcement that the Freedesktop project is dropping OpenH264 from the Freedesktop SDK for Flatpak applications and runtimes.
Some Flatpak applications that depend on the Freedesktop runtime version 23.08 will lose H.264 playback support starting with the release scheduled for April, unless application developers replace it with the ffmpeg-full extension. The 24.08 runtime is unaffected, and future releases will include a new codecs-extra extension to replace OpenH264 that includes FFmpeg with support for a number of patented codecs.
Considering all things, I think and hope we made the correct decision and hopefully the new org.freedesktop.Platform.codecs-extra works out. libx264, libx265 and others are built from source and there are no binaries or extra-data involved. So we should theoretically be able to patch and fix any issues that come up in the future.
Apart from all this, I'm slightly worried at the prospects of legal issues cropping up with this setup and also that the new extension contains "too much", but we will have to see where things flow.
Development quote of the week
These are the same people who want to make your car play an advertisement while you're at a stoplight or have your TV harvest your viewing habits to sell to the highest bidder or make it impossible to own any digital goods so you have to rent them for a monthly fee forever. Just think about what that sort of person would do with the kind of power they're attempting to take now.
I don't understand how these people live with themselves. I suspect they're pretty miserable. They already have everything and it's not enough.
I like writing software because it's challenging and interesting and I can make tools that automate boring and tedious stuff. For money, I work on tools that automate boring and tedious business stuff. If I have a repetitive task on the computer, I'll have way more fun if I can write a little script to automate it. Even better is writing a little script for somebody else: I get to solve a puzzle and make somebody's day. I love that. I wish this were more accessible to more people.
I will never, ever understand how someone can bring any amount of misery, big or small, to another person's life to make a buck.
Page editor: Daroc Alden
Next page:
Announcements>>