Uutils on Jon Seager

Adopting sudo-rs By Default in Ubuntu 25.10

Tue, 06 May 2025 00:00:00 +0000

This article was originally posted on the Ubuntu Discourse, and is reposted here. I welcome comments and further discussion in that thread.

Introduction #

Following on from Carefully But Purposefully Oxidising Ubuntu, Ubuntu will be the first major Linux distribution to adopt sudo-rs as the default implementation of sudo, in partnership with the Trifecta Tech Foundation

The change will be effective from the release of Ubuntu 25.10. You can see the Trifecta Tech Foundation’s announcement here.

What is `sudo-rs`? #

sudo-rs is a reimplementation of the traditional sudo tool, written in Rust. It’s being developed by the Trifecta Tech Foundation (TTF), a nonprofit focused on building secure, open source infrastructure components. The project is part of the Trifecta Tech Foundation’s Privilege Boundary initiative, which aims to handle privilege escalation with memory-safe alternatives.

The sudo command has long served as the defacto means of privilege escalation on Linux. As described in the original post, Rust provides strong guarantees against certain classes of memory-safety issues, which is pivotal for components at the privilege boundary.

The sudo-rs team is collaborating with Todd Miller, who’s maintained the original sudo for over thirty years. sudo-rs should not be considered a fork in the road, but rather a handshake across generations of secure systems. Throughout the development of sudo-rs, the TTF team have also made contributions to enhance the original sudo implementation.

The sudo-rs project is designed to be a drop in replacement for the original tool. For the vast majority of users, the upgrade should be completely transparent to their workflow. That said, sudo-rs is a not a “blind” reimplementation. The developers are taking a “less is more” approach. This means that some features of the original sudo may not be reimplemented if they serve only niche, or more recently considered “outdated” practices.

Erik Jonkers, Chair of the Trifecta Tech Foundation explains:

While no piece of software - in any language - is flawless, we believe the transition to Rust in systems programming is a vital step forward, it is very exciting to see Ubuntu committing to sudo-rs and taking the lead in moving the needle.

Sponsoring Mainstream Adoption #

Leading the mainstream adoption of a replacement to such a universally understood tool comes with responsibility. Before committing to ship sudo-rs in Ubuntu 26.04 LTS, we’ll test the transition in Ubuntu 25.10. We’re also sponsoring the development of some specific items, which has manifested as Milestone 5 in the upstream project:

Coarse-grained shell escape prevention (NOEXEC) on Linux (See PR #1073)
The ability to control AppArmor profiles (First PR #1067)
A sudoedit implementation
Support for Linux Kernels older than version 5.9

The final item may seem out of place, but because Ubuntu 20.04 LTS is still in support, without this work there could be situations where sudo fails to function if, for example, a 26.04 LTS OCI container was run on a 20.04 LTS host!

The team have also already begun work on ensuring that the test-suite is as compatible as possible with Ubuntu, to ensure any issues are caught early.

This isn’t just about shipping a new binary. It’s about setting a direction. We’re not abandoning C, or even rewriting all the utilities ourselves, but by choosing to replace one of the most security-critical tools in the system with a memory-safe alternative, we’re making a statement: resilience and sustainability are not optional in the future of open infrastructure.

Progress on `coreutils` #

Since the initial announcement, we’ve been working hard to more clearly define a plan for the migration to uutils coreutils in 25.10 and beyond. Similarly to our engagement with the Trifecta Tech Foundation, we’re also sponsoring the uutils project to ensure that some key gaps are closed before we ship 25.10. The sponsorship will primarily cover the development of SELinux support for common commands such as mv, ls, cp, etc.

The first step toward developing SELinux support was to add support for automated testing in Github Actions, since then the maintainers have begun work on the actual implementation.

The other feature we’re sponsoring is internationalisation support. At present, some of the utility implementations (such as sort) have an incomplete understanding of locales, and therefore may yield unexpected results. We expect that these two features should land in time for us to ship in 25.10, and we’ll continue to work with the uutils project throughout the 26.04 LTS cycle to close any remaining gaps we identify in the interim release.

One of the major concerns outlined in Julian’s post is about binary size. We’ve got a few tricks we can play here to get the size down, and there is already some conversation started upstream in Debian on how that might be achieved. There are also security implications, such as AppArmor’s lack of support for multi-call binaries. We’re currently working with the respective upstreams to discuss addressing this systematically, through in the interim we may need to build small wrapper binaries to enable compatibility with existing AppArmor profiles from the start.

Migration Mechanics #

Julian Klode posted recently on the Ubuntu Discourse outlining the packaging plan that will enable us both to migrate transparently to uutils coreutils, but also provide a convenient means for users to opt-out and switch back to GNU coreutils if they wish, or if they identify a gap in the new implementation. I expect this will be rare, but we want to make sure it’s as easy as possible to revert, and will be documenting this in detail before release.

Replacing coreutils isn’t as simple as swapping binaries. As an Essential package, its replacement must work immediately upon unpacking without relying on maintainer scripts, and without conflicting files across packages. To solve this, we’re introducing new coreutils-from-uutils and coreutils-from-gnu packages, as well as coreutils-from itself. For all the gory details, see the Discourse post!

The packaging work required to switch to sudo-rs is somewhat less complicated than with coreutils. The package is already available in Ubuntu (which you can still test on Ubuntu 24.04, 24.10 and 25.04 with oxidizr!), but unlike coreutils, sudo is not an Essential package, so we’ll be able to make use of the Debian alternatives system for the transition.

Summary #

Things are progressing nicely. We’ve established strong, productive relationships and are sponsoring work upstream to make these transitions viable.

We’ve got a strategy for migrating the default implementation of coreutils and sudo in Ubuntu 25.10 which will enable a seamless revert in cases where that is desired. While sudo-rs will be the default in 25.10, the original sudo will remain available for users who need it, and we’ll be gathering feedback to ensure a smooth transition before the 26.04 LTS.

Additionally, we’ve begun investigating the feasibility of providing SequoiaPGP and using it in APT instead of GnuPG. SequoiaPGP is a new OpenPGP library with a focus on safety and correctness, written in Rust. The GnuPG maintainers have recently forked the OpenPGP standard and are no longer compliant with it. Sequoia provides a modern alternative to GnuPG with strict behavior, and is already used in various other systems. More details to follow!

Stay tuned!

Carefully But Purposefully Oxidising Ubuntu

Wed, 12 Mar 2025 00:00:00 +0000

This article was originally posted on the Ubuntu Discourse, and is reposted here. I welcome comments and further discussion in that thread.

Introduction #

Last month I published Engineering Ubuntu For The Next 20 Years, which outlines four key themes for how I intend to evolve Ubuntu in the coming years. In this post, I’ll focus on “Modernisation”. There are many areas we could look to modernise in Ubuntu: we could focus on the graphical shell experience, the virtualisation stack, core system utilities, default shell utilities, etc.

Over the years, projects like GNU Coreutils have been instrumental in shaping the Unix-like experience that Ubuntu and other Linux distributions ship to millions of users. According to the GNU website:

The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system.

This package provides utilities which have become synonymous with Linux to many - the likes of ls, cp, and mv. In recent years, there has been an effort to reimplement this suite of tools in Rust, with the goal of reaching 100% compatibility with the existing tools. Similar projects, like sudo-rs, aim to replace key security-critical utilities with more modern, memory-safe alternatives.

Starting with Ubuntu 25.10, my goal is to adopt some of these modern implementations as the default. My immediate goal is to make uutils’ coreutils implementation the default in Ubuntu 25.10, and subsequently in our next Long Term Support (LTS) release, Ubuntu 26.04 LTS, if the conditions are right.

But… why? #

Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change. These utilities are at the heart of the distribution - and it’s the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me.

The Rust language, its type system and its borrow checker (and its community!) work together to encourage developers to write safe, sound, resilient software. With added safety comes an increase in security guarantees, and with an increase in security comes an increase in overall resilience of the system - and where better to start than with the foundational tools that build the distribution?

I recently read an article about targeting foundational software with Rust in 2025. Among other things, the article asserts that “foundational software needs performance, reliability — and productivity”. If foundational software fails, so do all of the other layers built on top. If foundational packages have performance bottlenecks, they become a floor on the performance achievable by the layers above.

Ubuntu powers millions of devices around the world, from servers in your data centre, to safety critical systems in autonomous systems, so it behooves us to be absolutely certain we’re shipping the most resilient and trustworthy software we can.

There are lots of ways to achieve this: we can provide long term support for projects like Kubernetes, we can assure the code we write, and we can strive to achieve compliance with safety-centric standards, but another is by shipping software with the values of safety, soundness, correctness and resilience at their core.

That’s not to throw shade on the existing implementations, of course. Many of these tools have been stable for many years, quietly improving performance and fixing bugs. A lovely side benefit of working on newer implementations, is that it sometimes facilitates improvements in the original upstream projects, too!

I’ve written about my desire to increase the number of Ubuntu contributors, and I think projects like this will help. Rust may present a steeper learning curve than C in some ways, but by providing such a strong framework around the use of memory it also lowers the chances that a contributor accidentally commits potentially unsafe code.

Introducing `oxidizr` #

I did my homework before writing this post. I wanted to see how easy it was for me to live with these newer implementations and get a sense of their readiness for prime-time within the distribution. I also wanted a means of toggling between implementations so that I could easily switch back should I run into incompatibilities - and so oxidizr was born!

oxidizr is a command-line utility for managing system experiments that replace traditional Unix utilities with modern Rust-based alternatives on Ubuntu systems.

The oxidizr utility enables you to quickly swap in and out newer implementations of certain packages with relatively low risk. It has the notion of Experiments, where each experiment is a package that already exists in the archive that can be swapped in as an alternative to the default.

Version 1.0.0 supports the following experiments:

How does it work? #

Each experiment is subtly different since the paths of the utilities being replaced vary, but the process for enabling an experiment is generally:

Install the alternative package (e.g. apt install rust-coreutils)
For each binary shipped in the new package:
- Lookup the default path for that utility (e.g which date)
- Back up that file (e.g. cp /usr/bin/date /usr/bin/.date.oxidizr.bak)
- Symlink the new implementation in place (e.g. ln -s /usr/bin/coreutils /usr/bin/date)

There is also the facility to “disable” an experiment, which does the reverse of the sequence above:

For each binary shipped in the new package:
- Lookup the default path for the utility (e.g which date)
- Check for and restore any backed up versions (e.g cp /usr/bin/.date.oxidizr.bak /usr/bin/date)
Uninstall the package (e.g. apt remove rust-coreutils)

Thereby returning the system back to its original state! The tool is covered by a suite of integration tests which illustrate this behaviour which you can find on Github

Get started #

⚠️ WARNING ⚠️: oxidizr is an experimental tool to play with alternatives to foundational system utilities. It may cause a loss of data, or prevent your system from booting, so use with caution!

There are a couple of ways to get oxidizr on your system. If you already use cargo, you can do the following:

1

cargo install --git https://github.com/jnsgruk/oxidizr

Otherwise, you can download and install binary releases from Github:

1
2


# Download version 1.0.0 and extract to /usr/bin/oxidizr
curl -sL "https://github.com/jnsgruk/oxidizr/releases/download/v1.0.0/oxidizr_Linux_$(uname -m).tar.gz" | sudo tar -xvzf - -C /usr/bin oxidizr

Once installed you can invoke oxidizr to selectively enable/disable experiments. The default set of experiments in v1.0.0 is rust-coreutils and sudo-rs:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Enable default experiments
sudo oxidizr enable
# Disable default experiments
sudo oxidizr disable
# Enable just coreutils
sudo oxidizr enable --experiments coreutils
# Enable all experiments without prompting with debug logging enabled
sudo oxidizr enable --all --yes -v
# Disable all experiments without prompting
sudo oxidizr disable --all --yes

The tool should work on all versions of Ubuntu after 24.04 LTS - though the diffutils experiment is only available from Ubuntu 24.10 onward.

The tool itself is stable and well covered with unit and integration tests, but nonetheless I’d urge you to start with a test virtual machine or a machine that isn’t your production workstation or server! I’ve been running the coreutils and sudo-rs experiments for around 2 weeks now on my Ubuntu 24.10 machines and haven’t had many issues (more on that below…).

How to Help #

If you’re interested in helping out on this mission, then I’d encourage you to play with the packages, either by installing them yourself or using oxidizr. Reply to the Discourse post with your experiences, file bugs and perhaps even dedicate some time to the relevant upstream projects to help with resolving bugs, implementing features or improving documentation, depending on your skill set.

You can also join us to discuss on our Matrix instance.

Next Steps #

Earlier this week, I met with @sylvestre to discuss my proposal to make uutils coreutils the default in Ubuntu 25.10. I was pleased to hear that he feels the project is ready for that level of exposure, so now we just need to work out the specifics. The Ubuntu Foundations team is already working up a plan for next cycle.

There will certainly be a few rough edges we’ll need to work out. In my testing, for example, the only incompatibility I’ve come across is that the update-initramfs script for Ubuntu uses cp -Z to preserve selinux labels when copying files. The cp, mv and ls commands from uutils don’t yet support the -Z flag, but I think we’ve worked out a way to unblock that work going forward, both in the upstream and in the next release of Ubuntu.

I’m going to do some more digging on sudo-rs over the coming weeks, with a view to assessing a similar transition.

Summary #

I’m really excited to see so much investment in the foundational utilities behind Linux. The uutils project seems to be picking up speed after their recent appearance at FOSDEM 2025, with efforts ongoing to rework procps, util-linux and more.

The sudo-rs project is now maintained by the Trifecta Tech Foundation, who are focused on “open infrastructure software in the public interest” . Their zlib-rs recently released v0.4.2, which appears to now be the fastest API-compatible zlib implementation. They’re also behind the Pendulum Project and ntpd-rs for memory-safe time synchronisation.

With Ubuntu, we’re in a position to drive awareness and adoption of these modern equivalents by making them either trivially available, or the default implementation for the world’s most deployed Linux distribution.

We will need to do so carefully, and be willing to scale back on the ambition where appropriate to avoid diluting the promise of stability and reliability that the Ubuntu LTS releases have become known for, but I’m confident that we can make progress on these topics over the coming months.

Uutils on Jon Seager

Adopting sudo-rs By Default in Ubuntu 25.10

Introduction #

What is sudo-rs? #

Sponsoring Mainstream Adoption #

Progress on coreutils #

Migration Mechanics #

Summary #

Carefully But Purposefully Oxidising Ubuntu

Introduction #

But… why? #

Introducing oxidizr #

How does it work? #

Get started #

How to Help #

Next Steps #

Summary #

What is `sudo-rs`? #

Progress on `coreutils` #

Introducing `oxidizr` #