Carefully But Purposefully Oxidising Ubuntu

[zmc]

This is fixing what isn’t broken, for no net benefit and the potential to break things that have been stable for a very long time. There are plenty of actual bugs to chase. Don’t create more.

[ogra]

This is likely the reason why it is optional
Indeed you want to collect all the new bugs in advance before switching the default, so people can opt in to help and find still open bugs

[zmc]

This shouldn’t be the default. Support the existing software instead of creating problems and fragmentation. I checked the CVE’s for coreutils, this isn’t about security.

[wxl]

@zmc

I checked the CVE’s for coreutils, this isn’t about security.

Looking at the original post:

@jnsgruk

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

So the issue isn’t about current CVEs. It’s about defending against potential future ones.

Before suggesting that there’s some problem being created by this suggestion, you should probably test it out and report any problems. Otherwise, despite you might be needlessly complaining about supposedly needless effort.

[zmc]

So you’re postulating that this software would be less likely to create instabilities and vulnerabilities than a body of utilities that have been improved, tested and used in production environments of all kinds in some cases for almost 35 years?

[wxl]

Again, please read the original post:

@jnsgruk

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

So by using Rust, you end up with something that is more or less inherently more safe and secure. Software can achieve this by other means (such as is the case with coreutils: extensive use and refinement over a long period of time), but simply having it in Rust makes it more future proof against vulnerabilities that have yet to be discovered in coreutils, or ones that may unintentionally be created by adding additional features.

And like I said, don’t knock it 'til you try it.

[zmc]

You have avoided the question. “…but it will be written in Rust so it will be better.” is a poor argument for rewriting stable software.

Try reading the post:
“…reimplement this suite of tools in Rust, with the goal of reaching 100% compatibility with the existing tools.”

Then:
“My immediate goal is to make uutils’ coreutils implementation the default in Ubuntu 25.10”

Followed by a warning that it may break your system in a fundamental way.

The project isn’t finished, currently experimental and unstable, and being considered for being the default implementation.

There is no clear benefit, this proposal is reckless at best.

[wxl]

@zmc

You have avoided the question.

Nope. I elaborated on it. If you want a more simple answer: “yes.”

@zmc

“…but it will be written in Rust so it will be better.” is a poor argument for rewriting stable software.

If you don’t understand the specific points mentioned about the Rust language, then you don’t understand how it ensures memory safety, and how this necessarily leads to more stable software.

@zmc

The project isn’t finished, currently experimental and unstable, and being considered for being the default implementation.

Yes, all of that’s correct, but fails to acknowledge the entirety of the post:

@jnsgruk

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

Put another way: the plan is to make it default, but plans are meant to be broken. The goal will only be met if stability and reliability can be insured.

Since your concern seems to be about stability and reliability, I don’t think you should have much of a concern.

So again, instead of needlessly complaining, I’d urge you to try to help test. If you’re dead set on being opposed to the idea no matter what, maybe work really hard at finding as many problems as you can and reporting them.

[zmc]

Just because Rust encourages memory safety doesn’t negate the fact that putting code that’s not even finished being written into production. The only reason given for implementing this in the first place is “There might be an undiscovered memory related bug somewhere in gnu coreutils”.

You are introducing code that’s unfinished and known to be buggy intentionally. For a widely used distribution that’s pretty gross negligence. I will not test to try to improve what’s unnecessary, ill advised and offers some vague hand waving as a benefit. What is the best way to oppose this project altogether and support it’s removal?

[ian-weisser]

Enabling Slow Mode to prevent any particular user from dominating the conversation.

Let’s all return to a constructive perspective.

Reminder: Name-calling and strong-opinions are a quick path to getting muted or banned. We expect professional behavior here.

Slow mode will prevent folks from posting…and editing. Be very sure you are saying what you really want to say (in a professional and constructive manner) before clicking that blue button. You won’t be able to take it back.

[3v1n0]

@jnsgruk

sudo-rs

That’s an interesting project, although there are few things to consider here:

• sudoedit / sudo -e are not supported yet
• I feel I’ve to port there an extra security check we landed to sudo and su [that’s handled here now].
• In the long run I think that we want to actually make sudo to be a wrapper of run0 instead that tackles various security issues

[jnsgruk]

Indeed sudoedit is missing at the moment, but I’m working with the Trifecta Tech Foundation folks on a plan that would see that landed before the feature freeze next cycle

• In the long run I think that we want to actually make sudo to be a wrapper of run0 instead that tackles various security issues

Possibly, but not definitely. There are cases (like some containers) where that may be less appropriate. I’m not ruling it out, but it’s not simple.

[ogra]

@jnsgruk

• In the long run I think that we want to actually make sudo to be a wrapper of run0 instead that tackles various security issues

Possibly, but not definitely. There are cases (like some containers) where that may be less appropriate. I’m not ruling it out, but it’s not simple.

That would also mean we’re on our own too, not benefiting from debian maintaining it as a default for us …

[3v1n0]

@jnsgruk

Possibly, but not definitely. There are cases (like some containers) where that may be less appropriate. I’m not ruling it out, but it’s not simple.

Yeah, I’ve no many objections in headless scenarios, while in a desktop setup run0 is meant to fix the lack of context of an authentication request.

However looking a bit more on the sudo-rs code it seems a bit immature yet TBH (and I also agree with @ogra that it implies an extra maintenance burden for something that has an high security impact, where more eyese are always better).

[mylinde]

It would be glade if we could be a bit more up-to-date.

• latest release of rust-coreutils 0.0.30
• latest release of sudo-rs 0.2.5
• latest release of rust-findutils 0.7.0

[jbicha]

Except for sudo-rs 0.2.5 (which was only released 2 days ago), Ubuntu 25.04 does have the latest versions of the things you listed.

[mylinde]

… Pre-release. The Noble packages stuck at 0.0.24-2, 0.2.2-1, 0.4.2-3. The maintainers could take a few minutes here so that you don’t have to get more up-to-date packages from somewhere else or build them by yourself.

[mylinde]

sudo-rs 0.2.5-1 released today in Plucky, rust-coreutils 0.0.27-3 and rust-findutils 0.7.0-3 from Plucky are also working in Noble. So, every thing is fine.

Keep going

[YamiYukiSenpai]

Tried in 25.10 in a new VM

$ sudo oxidizr --no-compatibility-check enable
> Continue? Yes
2025-07-28T03:53:52.545167Z  INFO Updating apt package cache
2025-07-28T03:53:54.204850Z  INFO Installing and configuring rust-coreutils
2025-07-28T03:54:01.443577Z  INFO Installing and configuring sudo-rs
Error: Failed to run command 'apt-get install -y sudo-rs': E: Sub-process /usr/bin/dpkg returned an error code (1)

taliara69@taliara69-evie-vm:~$ sudo apt install sudo-rs
Solving dependencies... Error!  
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Unsatisfied dependencies:
 sudo-rs : Breaks: sudo (< 1.9.16p2-1ubuntu2~)
           Breaks: sudo:i386 (< 1.9.16p2-1ubuntu2~)
Error: Unable to satisfy dependencies. Reached two conflicting decisions:
   1. sudo:amd64=1.9.16p2-1ubuntu1 is selected for install because:
      1. sudo:amd64 is selected for install
      2. sudo:amd64 is available in version 1.9.16p2-1ubuntu1
   2. sudo:amd64=1.9.16p2-1ubuntu1 is not selected for install because:
      1. sudo-rs:amd64=0.2.5-5ubuntu3 is selected for install
      2. sudo-rs:amd64 Breaks sudo (< 1.9.16p2-1ubuntu2~)
         [selected sudo-rs:amd64]

[jnsgruk]

The tool is not supported in 25.10, which is why you had to use the scary no-compatibility-check flag

This error is likely due to some instability in the transition, which will be worked out as we get closer to the release!