This is a follow-up to Jon’s original post on Carefully (but purposefully) oxidising Ubuntu and Julian’s migration spec for 25.10. We promised transparency throughout this process, and this post is written in that spirit.

What happened after the announcement

Following the decision to adopt rust-coreutils, we got to work. Any package shipped by default in Ubuntu must be promoted to Ubuntu Main, which requires passing a thorough security review. We quickly assembled an internal team spanning Ubuntu Foundations (@juliank, @bamf0) and Ubuntu Security (@sarnold, @hlibk) to collaborate closely with the upstream uutils project.

Early in the process, our assessment surfaced some serious concerns, and we realised that an internal review alone would not be sufficient. To gain the level of confidence required for an LTS release, we decided to commission an independent external security audit.

Partnering with Zellic

We partnered with Zellic, a top-tier security research firm staffed by world-renowned competitive hackers and infosec experts. The audit was conducted in two phases:

  • Round 1 (Dec 2025 - Jan 2026): Audit of high-priority utilities, the most security-sensitive tools in the coreutils suite.

The full Zellic audit report is available here: uutils-coreutils-Zellic-Audit-Report.pdf

  • Round 2 (Feb 2026 - Mar 2026): Audit of the remaining utilities. In this phase, Zellic contributed mitigations directly upstream as pull requests (30).

Across both rounds, 113 (73+40) issues of varying severity were identified. All findings were coordinated and reported upstream:

The upstream community responded swiftly and the vast majority of issues have been addressed and resolved.

Current status for 26.04 LTS

We shipped rust-coreutils as the default in Ubuntu 25.10 to maximise real-world testing ahead of the LTS. Based on the audit findings and remediation progress, here is where we stand for Ubuntu 26.04 LTS.

Our plan is to address the remaining issues as soon as possible and target Ubuntu 26.10 with 100% rust-coreutils.

Conclusion

This effort has been a genuine collaboration across organisational boundaries, and we’d like to thank:

  • Sylvestre Ledru and the uutils community for outstanding upstream leadership and responsiveness to the audit findings.
  • Zellic - their rigorous audit is a key reason we are confident in shipping rust-coreutils in an LTS release.
  • The open source community at large - for contributions in the form of code, bug reports, testing, and feedback.

We’d love your help in making rust-coreutils rock-solid. If you’re running Ubuntu 26.04 (or 25.10), please put the new coreutils through their paces, especially in your real-world workflows, scripts, and CI pipelines. If you encounter any unexpected behaviour or compatibility issues, please file a bug:

This migration has been a success overall. We remain committed to completing the transition and will continue to provide updates as work progresses.

CVE disclosures

As part of this transparency commitment, we are disclosing the following CVEs identified during the audit process:

First let me say I appreciate the openness and honesty here. You won my respect by doing it like this. Which in the tech world for the past 2 decades being like this is a rare thing. I am install installing 26.04 tomorrow like a champ.

thanks uutils maintainers. thank you Canonical for pushing for the last miles.

Especially given that

cp, mv, and rm continue to be provided by GNU coreutils in 26.04[,]

why wasn’t the GNU coreutils package (gnu-coreutils) refreshed – at least to v9.10-1 which also landed in Debian and which has been published upstream months ago – ahead of the 26.04 LTS GA? (Reminder: The coreutils-from-gnu package should still allow users to delay the switch to the “Rust counterpart” until they deem it safe/safe to avoid the above mixture of utilities.)

Can we at least expect a timely SRU for 26.04?

5

As far as I can tell, GNU coreutils 9.10 was released upstream on 4 February 2026, and entered Debian on 26 February 2026. Ubuntu does time-based releases, and the cut-off date to autosync from Debian for the upcoming LTS release was 19 February 2026, in order to stablise for release. So it didn’t make it in time, and will likely be in the next release instead.

I think an SRU is unlikely due to the risk involved. Usually, to minimise risk of regression to users, we only cherry-pick specific, high impact, targeted fixes at this stage. But if an Ubuntu developer thinks otherwise, proposes and prepares such an update, it will be considered on its merits.

6

Thank you for the update @ravi-sharma.

Section 1.3 of the report explicitly states that “source build pipelines and distribution packaging were not evaluated.”

Has software supply chain security been evaluated for rust-coreutils?

https://github.com/uutils/coreutils/blob/main/Cargo.lock file mentions numerous dependencies.

Have these dependencies been audited?

Are there measures to prevent supply-chain-related security incidents?

7

Hi @dwms,

Rust supply-chain security is an issue we’re actively working on. During the last cycle I implemented support for cargo-auditable on Launchpad, which embeds a SBOM into the final binaries. It’s enabled as a trial run for a few well-known Rust packages, including sudo-rs. (rust-coreutils has a somewhat bespoke build process meaning that we could not plug-and-play cargo-auditable support, unfortunately. We hope to ship SBOMs for cargo-auditable at some point, though.)

Cargo-auditable is documented in the release notes here: https://documentation.ubuntu.com/release-notes/26.04/changes-since-previous-interim/#rust-cargo-auditable. Stay tuned for a blog post! (It’s written but unpublished.)

8

Thank you @petrakat. I appreciate the transparency and I am interested to learn more about cargo-auditable integration with launchpad. I see how it can help to identify packages containing rust binaries dependent on crates with known security vulnerabilities in absence of relevant APT metadata.

I looked at rust-coreutils and rust-sudo-rs source packages for 26.04 and it appears that source code of dependency crates is bundled as part of package source (orig-rust-vendor archive), while rust-du-dust and rust-hyperfine, mentioned in the linked release notes, have no such archive while Cargo.lock file is present. Is it expected for Rust packages to have dependencies bypassing APT, by fetching crates directly from Rust Package Repository during build process or in other ways?

Is it correct to assume that security audit of all crates (specific versions) listed in Cargo.lock file used for build is the only thing that can help to proactively identify Rust dependencies with not yet known security vulnerabilities or malicious code injections?

I see that it is possible to fall back to GNU coreutils by swapping coreutils-from-uutils with coreutils-from-gnu and opt-out of sudo-rs through alternatives system as post-installation actions. Are there plans to keep this option for following LTS releases? Is there a way to opt-out of using coreutils-from-uutils and sudo-rs during installation, using official images?

Is it correct to assume that eventual core26 and other snap-related things will use coreutils-from-uutils (and sudo-rs?) with no opt-out mechanism?

9

  1. Many Rust packages “vendor” their dependencies, which means to include all the source code for all its dependencies in the repo instead of using apt. So it is expected for packages to (sometimes) bypass APT.
  2. You are correct that cargo-auditable does not detect new vulnerabilities; it simply lets you know if a binary was compiled with a known vulnerability. A security audit of all the crates would be one way to detect new vulnerabilities.
  3. I don’t know if you can opt-out of rust-coreutils/sudo-rs while installing, and I’m not sure about our future plans for gnu-coreutils vs rust-coreutils.

10

Cargo.lock file in rust-coreutils_0.8.0.orig.tar.gz contains 523 “[[package]]” entries. Is it correct to assume that rust-coreutils has 523 cargo dependencies, including transitive ones?

rust-vendor directory in rust-coreutils_0.8.0.orig-rust-vendor.tar.xz contains 409 sub-directories. Is it correct to assume that the package vendors 409 cargo dependencies? Are the remaining 523 - 409 = 114 dependencies fetched from Rust Package Registry during build?

First few pages of commit history of the uutils/coreutils Cargo.lock file at History for Cargo.lock - uutils/coreutils · GitHub show around 2-3 updates per day, many of these authored by “renovate[bot]” account. Section 2.3 “Scope” of the report points to specific programs at version 3a07ffc5a9bd4c283e75afa548ba1f1957bad242 of GitHub - uutils/coreutils: Cross-platform Rust rewrite of the GNU coreutils · GitHub repository. It is not clear if rust-coreutils cargo dependencies are covered by the security assesment.

Have cargo dependencies of rust-coreutils, rust-sudo-rs and other (if any) system packages been audited as part of internal Canonical reviews, mentioned by @ravi-sharma, or Zellic? Have the cargo dependencies been checked for not yet known security vulnerabilities and/or malicious code injections in any other way at least once?

Are all cargo dependency updates (new crates or new versions of referenced crates) of system packages being verified to ensure that no not yet known malicious code and/or security vulnerabilities have been introduced since the last audit/checkup (if any)?

Who can answer questions that are not relevant to your expertise? Are they willing to provide response in this thread?