How Ubuntu Is Using Rust to Rebuild Core System Tools

This post is based on a RustRover livestream hosted by our Developer Advocate, Orhun Parmaksız, with Jon Seager, VP of Engineering at Canonical. They talked about Ubuntu, Rust, and the future of core system software, including how Canonical is approaching Rust adoption and why some of the most important changes are happening in parts of the system users rarely see but depend on every day.

Watch the full video here 👇

There’s a version of this story where someone rewrote ls in Rust and called it a revolution. Ubuntu is taking a more deliberate approach. It started with a question Jon Seager asked himself shortly after he took on leadership of Ubuntu: what got us here probably won’t get us through the next 20 years – so what do we change?

The answer, it turns out, involved a lot of memory safety, a healthy appetite for calculated risk, and more opinions about the sudo password prompt than anyone anticipated.

Why Ubuntu is betting on Rust

Ubuntu has been around for over 20 years. It runs on 15 million deployments, and you’ll find it on servers, desktops, edge devices, and inside cars. That reach is exactly the reason why Jon’s thinking about security and resilience isn’t abstract. It has to work at scale, in a wide range ofacross industries, and in safety-critical systems where a crash isn’t just inconvenient.

When Jon joined as VP of Engineering, Rust wasn’t necessarily the plan. His thinking changed as he looked at what Ubuntu would need from its platform over the next couple of decades.

“In my opinion, Rust provides the most compelling set of tools of the systems programming languages we have available for progressing that agenda.”

Jon Seager VP of Engineering at Canonical

Security, resilience, and memory safety

The obvious argument for Rust is memory safety, but Jon frames it a bit differently. He talks about resilience as sitting at the intersection of security and reliability. He treats security and reliability as closely related, but distinct problems

An unhandled panic can create both a security risk and a reliability failure. In automotive systems, industrial control software, and safety-critical infrastructure, that difference matters less than the outcome: the thing stopped working when it shouldn’t have. Fewer memory bugs mean fewer crashes, fewer attack surfaces, and a system that’s harder to break in general. Canonical’s revenue is largely built on patching vulnerabilities and providing support.

Jon Seager’s long-term platform view

Jon describes the move to Rust as a long-term platform decision rather than a rewrite campaign.

The technical case is only part of the story. Jon is just as interested in who Rust attracts. Those are developers who care about correctness, think carefully about safety, and want to work on the kinds of problems Ubuntu needs solved. By building more of the platform in Rust, Canonical is creating a clearer path for that community to contribute.

GNU coreutils has existed for 30 years, and it’s great software. Jon was clear about that. But 30 years also means 30 years of accumulated bugs, and the argument that the Rust version has bugs too misses the point. The longer-term question is whether the platform ends up in a better place 20 years from now if more of its base is memory-safe by default.

What is changing in Ubuntu

Ubuntu is not rewriting everything in Rust. The headline version of this story often makes it sound that way, but Canonical is making selective, deliberate replacements where the security and maintenance case is strongest, starting at the boundary of LTS releases, where users have fallback options and the chances of getting it right are highest.

coreutils, sudo-rs, ntpd-rs, and UPKI

The first pieces landed in Ubuntu 26.04 LTS. uutils coreutils, the Rust reimplementation of GNU coreutils, shipped as the default with a goal of 100% bug-for-bug compatibility with the GNU tools.

sudo-rs is the other big one in 26.04, and it takes a very different approach. Where uutils aims to be a drop-in replacement, sudo-rs is asking a different question entirely: if you were designing sudo today, having learned 30 years of security lessons, what would it actually look like? The answer involves some deliberate behavior changes.

ntpd-rs is next on the list. Canonical announced in June 2026 that it’s funding the Trifecta Tech Foundation to bring ntpd-rs to Ubuntu as the default time synchronization utility, eventually replacing chrony and linuxptp with a single tool that handles NTP, NTS, and PTP. The plan is to archive it in Ubuntu 26.10, with a full default switch in Ubuntu 28.04.

UPKI takes a different approach. It’s a greenfield project built in collaboration with the Rustls project, aimed at bringing certificate revocation to Linux system utilities. That’s something that browsers figured out years ago, but that curl, wget, and OpenSSL still don’t handle. UPKI is targeting Ubuntu 26.10 as its first shipping milestone for certificate revocation.

Why ntpd-rs is more than a drop-in replacement

Accurate timekeeping is safety-critical in more places than it might seem: microcontrollers in planes, cars, and robots; cryptographic systems where keys rotate frequently; and positional systems where clock drift has real consequences. Chrony handles basic NTP well, but problems show up when you need PTP, the precision time protocol, which handles high-precision synchronization.

On Linux today, that means running chrony and linuxptp, and potentially a dedicated or satellite time source, then configuring all of them to talk to each other. Jon described it as “quite unfun,” which felt like an understatement. ntpd-rs is meant to collapse all of that into one tool with one configuration file, with the added benefit of being memory-safe and efficient.

The trade-offs

Jon was clear that they broke some things. They knew they would, but they did it anyway because they accepted short-term breakage in exchange for longer-term benefits and built the transition so people could step back if needed.

Compatibility vs. deliberate behavior changes

uutils coreutils is trying to be 100% compatible, so that differences from GNU behavior are treated as bugs, not features. In practice, that’s hard. One recent example Jon shared: when you tell head to read N bytes from an empty file, GNU coreutils returns zero. The uutils implementation initially returned an error, which is arguably more correct. But it broke a buried script in an Obsidian snap, so the maintainer changed it back to match the GNU behavior anyway. Compatibility first.

sudo-rs makes no such promise. It asks what sudo should be, not what it was. One change that generated a surprising amount of heat was that by default, sudo-rs now shows asterisks when you type your password in the terminal. What can look like a small UX change generated surprisingly strong reactions. Jon’s take was basically that the new behavior is better – they thought it through and stand by it.

Why Ubuntu rolled this out at an LTS boundary

The LTS timing is deliberate. Long-term support releases are when enterprises upgrade, and they’re also the moment where fallback options matter most. By making these changes at the LTS boundary, Canonical ensures that if something breaks for you specifically, you have 15 years of maintained support on the previous release while you work it out. The legacy utilities remain in the archive. Nobody is being forced into the new behavior on a live production system without warning.

Ubuntu Rust: Packaging and delivery

Shipping memory-safe system software is one thing. Actually getting Rust code into a Linux distribution at distro scale is another, and much of the unglamorous work happens at this stage.

Crates, cargo auditable, and snaps

Canonical takes a vendoring approach to Rust dependencies rather than packaging individual crates as separate debs. All the crates for a given package get bundled together into a tarball and shipped as part of the finished artifact, similar to how Nix handles it. That keeps the dependency surface manageable and makes the builds deterministic, even if they’re not reproducible in the formal sense.

Earlier in 2026, cargo auditable was rolled out across all Rust packages in the Ubuntu archive. Every Rust binary now carries an embedded SBOM (Software Bill of Materials) listing the exact crates and versions used to build it. When a package gets rebuilt, the SBOM updates automatically. That makes it easier to identify exactly which crate versions are present when a vulnerability is discovered.

Then there are snaps. Whatever your feelings about them, Jon acknowledges they solve a specific problem that’s hard to solve any other way at Ubuntu’s scale: getting modern software to run on old releases. Because snaps bring their own runtime, you can ship a snap built against Ubuntu 26.04 and have it run correctly on 22.04 or 24.04. For Rust packages with climbing MSRVs, that’s not a small thing. It’s also how JetBrains ships RustRover across multiple LTS versions, which came up in the conversation.

What comes next

Canonical is approaching this incrementally. Each release cycle, the team looks at where replacing or rebuilding a component would bring the clearest security or maintenance benefit.

More Rust in system software and ecosystem funding

After ntpd-rs and UPKI, compression libraries are next in focus. Canonical is looking at bzip2-rs, zlib-rs, and zstd-rs. There are trade-offs here too. One of the zstd implementations catches a class of unsafe operations that the current C library allows, but with some performance cost unless you turn those checks off. Whether to ship with the checks on or off is the kind of decision that sounds small, but isn’t.

Jon put it plainly during the stream. Ubuntu’s goal extends beyond shipping Rust code to upstream contributions, security audits, funding for maintainers, and involvement in conversations about supply chain security at the infrastructure level. Canonical also hopes that some of this work can be reused or adopted by other Linux distributions.

Watch other livestreams