- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
You must log in or # to comment.
TLDR:
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.
We have included the latest upstream release 0.8.0 in Ubuntu 26.04, which incorporates the bulk of the security fixes.
cp, mv, and rm continue to be provided by GNU coreutils in 26.04. These utilities have remaining open TOCTOU (time-of-check to time-of-use) issues (8 as of Apr 22, 2026) that need to be resolved before we are confident shipping them.
Our plan is to address the remaining issues as soon as possible and target Ubuntu 26.10 with 100% rust-coreutils.
Rust basedMIT licensed coreutilsI don’t think I’ll ever understand the constant complaints about the license. If it were the kernel or some software that was particularly unique, then I’d understand. However, there are many existing implementations of the coreutils programs that are already under permissive licenses. If someone didn’t want to use the GPL, they could just use one of those. This is partly why it is incredibly fiddly to write cross-platform shell scripts.
The mit license allows someone (some company) to modify the open source codebase and sell the result without making their modifications public.
It allows the software equivalent of the enclosure of the commons.
If there was a particularly large or significant and widespread codebase —like for example the coreutils— that was used everywhere and mit licensed, a company could make their own slightly different coreutils without publicizing the differences and use their position in the market to enclose the commons of knowledge about the use of that software. Such a situation would lead to a fractured feature ecosystem and confusion around best practices. In that environment, the biggest and most popular software distributor would benefit because their product would be most common and therefore the best target to design around.
I know there’s a lot of “coulds” and “woulds” in that sentence, but that’s exactly what happened in the 80s and 90s with the ostensibly open source Unix codebase and the reason why the gpl was invented.
It’s already fractured, as I literally mentioned. That’s why it’s hard to write cross-platform scripts. Part of the reason it’s fractured is that the implementations most commonly in use other than GNU coreutils are permissively licensed and thus cannot easily adopt unique features from GNU coreutils.
In any case, at this point, changing the coreutils license itself will not materially change much in terms of how fractured the existing landscape is given that people could already use Busybox, Toybox, programs from any of the BSD userlands, etc. if they didn’t want to use GNU coreutils for whatever reason.
Is rust-coreutils being developed by Canonical? Then it sounds like shooting themselves in the foot. Why give competitors a chance to take over a vital package that is at the core of their OS?
Some Canonical employees are working on it but it’s not originally a Canonical project.
mit lets companies take them without contributing back critical stuff like security fixes.
their money and resources are very important to keep foss alive and this relies a lot on the gpl because it just means they are forced to take some responsibility for the projects they use to make their billions.
That’s great, except they could already just use a permissively licensed implementation. This is in fact what a lot of companies already do. For instance, Android uses Toybox, macOS uses utilities originally ripped from NetBSD (mostly), etc.
Generally, a lot of companies also don’t contribute back fixes upstream. They’ll often just dump the code in some hidden away corner of their site as a giant source blob.
For something like coreutils, where a significant change is sort of unlikely in the first place, thinking the GPL makes a difference is bizarre to me.
Yeah…
A very, merry 🖕 to whoever decided to use a cuck license for this.
The team of over 200 rust developers involved with the project did. They wanted to avoid the “politics” and are not entertaining comments or explaining their decisions. It’s not up for discussion.
This is incredibly common in rust development.
E: apologies, it’s 530 contributors according to the uutils-coreutils blog.
🖕x 200 then
Any distro that packages this should package a libre version with GPL.
Eventually that option will go away.
Even if a decent number of the vulnerabilities closed by mit/rust coreutils are not exploitable or would require an insane chain, distros untouched by the perverse incentives of rust will eventually adopt them based solely on the number of closed bugs alone.
We are headed for the ibm/unix past of open source because the multipolar world we are headed towards mirrors the conditions of that past.
The tools of that transition happen to be rust/junior devs/ai, but if different tools were available that would generally reach those ends they would be in use instead.
Why are you hallucinating facts?
- There is no “team of 200 rust developers”.
- “<lang> developer” is not an identity.
- uutils is not a “professional” project, as in people are paid by the (non-existing) uutils company to work on it.
- The project started as personal hobby of one person during COVID, There were no 200 contributors who sprung up magically and simultaneously from the start.
They wanted to avoid the “politics” and are not entertaining comments or explaining their decisions. It’s not up for discussion.
If you think you saw a group of 200 people starting uutils and doing this. You should seek medical help.
I double checked myself and linked the 15 month old ledru blog post that has the actual claim and statements about rust-coreutils in my reply.
I did that before you replied to me, but it may have taken a little bit for edits to federate across instances.
The number is 530 contributors, not 200 rust developers, although I personally feel that because the project is in rust the word contributor and the phrase “rust developer” are interchangeable without incurring any accusation of manipulative language or purposeful deception.
I made no claim that uutils is a professional project. Nonetheless, the person who wrote the uutils blog post I linked is an employee of Mozilla and the author of the update in the op is an employee of canonical, the company that makes Ubuntu. This is not uncommon in all open source development regardless of licenses and is the reason I didn’t bring it up. Not enough people realize there are double digit big name projects maintained by some guy in Idaho and the overwhelming majority are shepherded by developers and maintainers in the pay of some company or another.
I never made a claim about who started the project to rewrite coreutils in rust.
The “reported upstream” link is broken (fixed link).
