Brief items

Traversal-resistant file APIs (The Go Blog)

Damien Neil has written an article for the Go Blog about path traversal vulnerabilities and the os.Root API added in Go 1.24 to help prevent them.

Root permits relative path components and symlinks that do not escape the root. For example, root.Open("a/../b") is permitted. Filenames are resolved using the semantics of the local platform: On Unix systems, this will follow any symlink in "a" (so long as that link does not escape the root); while on Windows systems this will open "b" (even if "a" does not exist).

Comments (2 posted)

Below: local privilege escalation (SUSE security team blog)

The SUSE Security Team blog has a post with a detailed analysis of a vulnerability (CVE-2025-27591) in the below tool for recording and displaying system data.

In January 2025, Below was packaged and submitted to openSUSE Tumbleweed. Below runs as a systemd service with root privileges. The SUSE security team monitors additions and changes to systemd service unit files in openSUSE Tumbleweed, and through this we noticed problematic log directory permissions applied in Below's code.

Comments (none posted)

Kernel release status

The current development kernel is 6.14-rc6, released on March 9. Linus said: "This release remains on track, nothing special to report".

Stable updates: 6.13.6, 6.12.18, 6.6.81, and 6.1.130 were released on March 7, followed by 6.6.82, with an i386-specific fix, on March 9.

The 6.13.7, 6.12.19, 6.6.83, 6.1.131, 5.15.179, 5.10.235, and 5.4.191 updates are all in the review process; they are due at any time.

Comments (none posted)

Quotes of the week

If we want filesystem corruption CVEs to be any other than security theatre, then we should be using the kernel CVE powers for the reason they were obtained in the first place. i.e. to force downstream distros to address issues they would otherwise ignore to help make our linux systems more reliable and secure.

— Dave Chinner

People have stuff to get done. If you disallow unprivileged filesystem mounts, they will just use sudo (or equivalent) instead. The problem is not that users are mounting untrusted filesystems. The problem is that mounting untrusted filesystems is unsafe.

Making untrusted filesystems safe to mount is the only solution that lets users do what they actually need to do. That means either actually fixing the filesystem code, or running it in a sufficiently tight sandbox that vulnerabilities in it are of too low importance to matter.

— Demi Marie Obenour

Comments (3 posted)

Ubuntu 25.04 (Plucky Puffin) progress

Matthieu Clemenceau has published a status update from the Foundations Team on Ubuntu 25.04 (Plucky Puffin) development to the Ubuntu Discourse forum. This includes updates on Ubuntu's adoption of Dracut as an alternative to initramfs-tools, a move to a single ISO for arm64 devices rather than device-specific images, and reverting the planned O3 optimization flags for Plucky Puffin.

Earlier in this cycle, we announced plans to enable the O3 optimization level for all Ubuntu packages by default. As part of this effort, we conducted extensive benchmarking, which revealed that while some workloads saw improvements, overall system performance slightly declined, and binary sizes increased. Given these results, we are likely to revert this change soon.

The beta for Ubuntu 25.04 is planned for March 27, with the final release scheduled on April 17.

Comments (13 posted)

Distributions quote of the week

The difficulty to know how long the trip through NEW [package queue] will take has a significant psychological impact. Close to my home, there is a railway crossing on a relatively busy track. If the barriers come down, it can mean a wait time from a minute (a single train) up to 20(!) minutes (with several and/or long trains in close succession). This does not happen very often, but you have no way of knowing in advance. Thus, people take significant detours to avoid that level crossing, as they'd rather add five minutes for certain to their trip than roll the dice for an unlucky quarter hour.

— Timo Röhling

Comments (none posted)

The LLVM project stabilizes its Fortran compiler

The LLVM project's Fortran compiler, which has for many years gone by the name "flang-new", will now simply be "flang", starting from LLVM's 20.1.0 release on March 4. The announcement, which includes details about the history of flang, comes after a long period of development and discussion. The community has considered renaming flang several times before now, but has always held off out of a feeling that the compiler was not yet ready. Now, the members of the project believe that flang has become stable and complete enough to earn its name.

We are almost 10 years from the first announcement of what would become LLVM Flang. In the LLVM monorepo alone there have been close to 10,000 commits from around 400 different contributors. Undoubtedly more in Classic Flang before that.

Comments (1 posted)

GStreamer 1.26.0 released

Version 1.26.0 of the GStreamer cross-platform multimedia framework has been released. Notable changes in this release include support for the H.266 Versatile Video Coding (VVC) codec, Low Complexity Enhancement Video Coding (LCEVC) support, closed caption improvements, and JPEG XS image codec support.

Comments (11 posted)

Framework Mono 6.14.0 released

Version 6.14.0 of Framework Mono has been announced.

This is the first release of Framework Mono from its new home at WineHQ. It includes work from the past 5 years that was never included in a stable release because no stable branch had been created in that time. Highlights are native support for ARM64 on macOS and many improvements to windows forms for X11.

See the release notes for a full list of new features and plans for future releases.

Comments (5 posted)

Python tail-call speedup based on LLVM regression

The Python project's recent switch to a tail-calling interpreter may not provide as large a speed advantage as initially thought. A blog post from Nelson Elhage gives the details. In short, switching to a tail-call-based interpreter accidentally works around an unfixed regression in LLVM 19. On other compilers, the performance benefit (while still present) is more moderate.

When the tail-call interpreter was announced, I was surprised and impressed by the performance improvements, but also confused: I'm not an expert, but I'm passingly-familiar with modern CPU hardware, compilers, and interpreter design, and I couldn't explain why this change would be so effective. I became curious – and perhaps slightly obsessed – and the reports in this post are the result of a few weeks of off-and-on compiling and benchmarking and disassembly of dozens of different Python binaries, in an attempt to understand what I was seeing.

Comments (16 posted)

Development quote of the week

A small team had gotten a grant to finally finish deploying the next-generation rewrite of PyPI, and decommission the legacy site. We'd been very public about the timeline, testing instructions, etc. A short time before the switchover date, a company realized that their code could not follow the HTTP 303 redirect our service was serving. They asked us to delay the migration and keep the old backend running. For a few months.

— Sumana Harihareswara (thanks to Paul Wise)

Comments (2 posted)