Agreed. Since GNU Coreutils is GPLv3 but uutils is MIT, my guess is eventually Canonical will start using "works like the GNU software except you don't have to comply with GPLv3" as a selling point for Ubuntu Core (their IoT focused distro). This would let them sell to companies who want to only permit signed firmware images to run on their devices, which isn't allowed under GPLv3.
If that's really the case, I wish they would just come out and say it and spare the rest of us the burden of trying to debate such a decision on its technical merits. (Of course, I am aware that they owe me nothing here.)
Assuming this theory is true then, what other GPLv3-licensed "core" software in the distro could be next on their list?
Busybox is frankly a horrible user experience, and will never be a good one. Its niche is to be as small as possible, as a single static executable, while providing most tools you need to get the job done in an embedded system. Bells and whistles like a shell that's nice to use, or a vi implementation with working undo/redo, or extensive built-in documentation in the form of --help output, are non-features which would make busybox worse for its primary use case.
I like how the first comment is asking "is anyone actually going to switch to this version?" and here we are with one of the major Linux distributions using it already, and already managed to ship a bug via it.
Brave of them to ship a Rust port of sudo as well.
It seems like I'm probably preaching to the choir, but what really is the attack surface with coreutils? I can't imagine there have been a lot of pwns as a result of the `date` command.
Untrusted input is often stored in files. Coreutils tools are often used to operate on those files.
As an obvious example, I sometimes download files from the Internet, then run coreutils sha256sum or the like on those files to verify that they're trustworthy. That means they're untrusted at the time where I use them as input to sha256sum.
If there's an RCE in sha256sum (unlikely, but this is a thought experiment to demonstrate an attack vector), then that untrusted file can just exploit that RCE directly.
If there's a bug in sha256sum which allows a malicious file to manipulate the result, then a malicious file could potentially make itself look like a trusted file and therefore get past a security barrier.
Maybe there's no bug in sha256sum, but I need to base64 decode the file before running sha256sum on it, using the base64 tool from coreutils.
If you use your imagination, I'm sure you yourself can think up plenty more use cases where you might run a program from GNU coreutils against untrusted user input. If it helps, here's a Wikipedia article which lists all commands from GNU coreutils: https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands
EDIT: To be clear, this comment is only intended to explain what the attack surface is, not to weigh in on whether rewriting the tools in Rust improves security. One could argue that it's more likely that the freshly rewritten sha256sum from uutils has a bug than that GNU sha256sum has a bug. The statement "tools from coreutils are sometimes used to operate on untrusted input and therefore have an attack surface worth exploring" is not the same as the statement "rewriting coreutils in Rust improves security". Personally, I'm excited for the uutils stuff, but not primarily because I believe it alone will directly result in significant security improvements in Ubuntu 25.10.
To play devil's advocate, who knows what kind of madness people are handing off to subprocess.run(["date"]) et al. They shouldn't, but I'd bet my last dollar it's out there.
I can certainly understand it for something like sudo or for other tools where the attack surface is larger and certain security-critical interactions are happening, but in this case it really seems like a questionable tradeoff, where the benefits in this specific case are abstract (theoretically no more possibility of any memory-safety bugs) but the costs are very concrete (incompatibility issues; and possibly other, new, non-memory-safety bugs being introduced with new code).
EDIT: Just to be clear, I'm otherwise perfectly happy that these experiments are being done, and we should all be better off for it and learn something as a result. Obviously somebody has assessed that this tradeoff has at least a decent probability of being a net positive here in some timeframe, and if others are unhappy about it then I suppose they're welcome to install another implementation of coreutils, or use a different distro, or write their own, or whatever.
OpenBSD has a lot of new stuff throughout the codebase.
No need for adding a bloated dependency (e.g. Rust) just because you want to re-implement "yes" in a "memory-safe language" when you probably have no reasons to.
You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way.
Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old.
See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.
I think it's mainly that it's a fun project and Rust is a lot nicer to work with than C. You're way more likely to see modern niceties and UX improvements in these ones than the old ones.
The thought of rewriting anything as intricate, foundational, and battle-tested as GNU coreutils from scratch scares me. Maybe I'd try it with a mature automatic C-to-Rust translator, but I would still expect years of incompatibilities and reintroduced bugs.
See also the "cascade of attention-deficit teenagers" development model.
Eh. People have written replacements for glibc because they didn't like something or another about it, and that seems to me to be way more fraught with risk than coreutils.
Folks also run into compatibility issues with musl as well. The biggest I recall was an issue with DNS breaking because musl didn’t implement some piece.
Fair enough. My gut sense is that C functions are simpler than shell commands, with a handful of parameters rather than a dozen or more flags, and this bug supports that -- they forgot to implement a flag in "date." But I haven't tried to do either, so I could be wrong.
This doesn't look like a bug, that is, something overlooked in the logic. This seems like a deliberately introduced regression. Accepting an option and ignoring it is a deliberate action, and not crashing with an error message when an unsupported option is passed must be a deliberate, and wrong, decision.
It's wrong (and coreutils get it right) but I don't see why it would have to be deliberate. It could easily just not occur to someone that the code needs to be tested with invalid options, or that it needs to handle invalid options by aborting rather than ignoring. (That in turn would depend on the crate they're using for argument parsing, I imagine.)
Could parsing the `-r` be added without noticing it somehow?
If it was added in bulk, with many other still unsupported option names, why does the program not crash loudly if any such option is used?
A fencepost error is a bug. A double-free is a bug. Accepting an unsupported option and silently ignoring it is not, it takes a deliberate and obviously wrong action.
It certainly doesn't look intentional to me- it looks like at some point someone added "-r" as a valid option, but until this surfaced as a bug, no one actually implemented anything for it (and the logic happens to fall through to using the current date).
I would say that Canonical is more at fault in this case.
I'm frankly appalled that an essential feature such as system updates didn't have an automated test that would catch this issue immediately after uutils was integrated.
Nevermind the fact that this entire replacement of coreutils is done purely out of financial and political rather than technical reasons, and that they're willing to treat their users as guinea pigs. Despicable.
What surprises me is that the job seems rushed. Implementation is incomplete. Testing seems patchy. Things are released seemingly in a hurry, as if meeting a particular deadline was more important for the engineers or managers of a particular department than the qualify of the product as a whole.
This feels like a large corporation, in the bad sense.
annoyingly, they don't link to the actual bug in question, just say:
> Systems with the rust-coreutils package version 0.2.2-0ubuntu2 or earlier have the bug, it is fixed in 0.2.2-0ubuntu2.1 or later.
based on the changelog [0] it seems to be:
> date: use reference file (LP: #2127970)
from there: [1]
> This is fixed upstream in 88a7fa7adfa048dabdffc99451d7aba1d9e6a9b6
which in turn leads to [2, 3]
> Display the date and time of the last modification of file, instead of the current date and time.
this is not the type of bug I was expecting, I assumed it would be something related to a subtle timezone edge case or whatever.
instead, `date -r` is supposed to print the modtime of a given file:
> date --utc -Is -r ~/.ssh/id_ed25519.pub
2025-04-29T19:25:01+00:00
> date --utc -Is
2025-10-23T21:46:47+00:00
and it seems like the Rust version just...silently ignored that expected behavior?
maybe I'm missing something? if not this seems really sloppy and not at all what I'd expect from a project aiming to replace coreutils with "safer" versions.
Neither this issue, which doesn't appear to be a bug at all but merely an unimplemented feature, nor the fact that uutils doesn't (yet) pass the entire testsuite, seem to me to at all be an indictment of the uutils project, merely a sign that it is incomplete. Which is hardly surprising when I get the impression it's primarily been a hobby project for a bunch of different developers. It does make me wonder about the wisdom of Ubuntu moving to it.
It's a part of Ubuntu 25.10 to get it ready for prime time for Ubuntu 26.04.
Users who need stability should use the LTS releases. The interim releases have always been more experimental, and have always been where Canonical introduces the big changes to ensure everything's mature by the time the LTS comes around.
Maybe the thought is that there will be more pressure now on getting all the tests to pass given the larger install base? It isn't a great way to push out software, but it's certainly a way to provide motivation. I'm personally more interested in whether the ultimate decision will be to leave these as the default coreutils implementation in the next Ubuntu LTS release version (26.04) or if they will switch back (and for what reason).
they have a tendency to try novel/different things, like upstart (init system), mir (desktop compositor (?))
and this is probably a net positive, there's now an early adopter for the project, the testsuite gets improved, and the next Ubuntu LTS will ship more modern tools
yeah, based on some more digging, it looks like a test case for `date --reference` in GNU coreutils was only added a few hours ago [0] so I assume it was in response to this bug.
but I don't think that should let the uutils authors off the hook - if `--reference` wasn't implemented, that should have been an error rather than silently doing the wrong thing.
after even more Git spelunking, it looks like that problem goes all the way back to the initial "Partial implemantion of date" [1] commit from 2017 - it included support for `--reference` in the argument parsing, including the correct help text, but didn't do anything with it, not even a "TODO: Handle this option" comment like `--set` has.
Is that true? If I make a product, and that product runs some embedded Linux system with GPLv3-licensed coreutils, are you confident that my product isn't infected by GPLv3?
Canonical is trying to position Ubuntu as a relevant player in the embedded space.
Oh, you mean specifically GPL v3 license, not any GPL license.
Yeah, broad tivoisation and patent clauses make it a problem, because making any patent litigation on unrelated grounds has potential to lose ability to ship the entire OS.
> But seriously. Rewriting C utilities that have been battle-tested for decades in Rust might be a good idea in the long term, but anyone could have predicted short-term hiccups.
How "long term" are we talking about that rewriting battle-tested, mission-critical C utils (which, as other posters noted, in this case often have minimal attack surfaces) actually makes sense?
>> Which is why I'm glad they're doing it! It seems like the kind of thing that one can be understandably scared to ever do, and I say this as one of the folks involved with getting some Rust in the Linux kernel.
Total zealot.
Reminder that one of the uutils devs gave a talk at FOSDEM where he used spurious benchmarks to falsely claim uutils's sort was faster, only for /g/ users to discover it was only because it was locale-unaware, and in fact was much slower:
> How "long term" are we talking about that rewriting battle-tested, mission-critical C utils (which, as other posters noted, in this case often have minimal attack surfaces) actually makes sense?
Makes me wonder if putting a similar amount of effort into building up proof/formal verification system for coreutils would have yielded better results security wise.
That's why it's called the bleeding edge. Rust dev culture is 99% bleeding edge. It is not a culture of stability. It is a culture of change and the latest and greatest. The language could be used in stable ways, but right now, it's not.
That's one heck of an extrapolation from one incident, or even one project, in a language that has been post-1.0 for a decade and has a wide variety of users with a wide variety of update/upgrade preferences and subcultures.
Which makes sense because in 2025 people have grown tired of lack of improvement so that some esoteric ass compiler from the 90s still works or someones 30 year old bash script still functions.
Pros and Cons either way for better or worse depending on your perspective.
I've largely lost patience with the current culture of sacrificing any backwards compatibility that is slightly inconvenient in the name of “improvement”.
That’s an argument against creating uuutils; it is a project that aims for coreutils 100% compatibility. eza, bat, ripgrep, etc are more exciting for at least having different features than coreutils
I was more commenting on the Rust community being ready to make breaking changes.
Personally while I think Rust is a decent language it would not have caught on with younger devs if C/C++ didn't have such a shitty devex that is stuck 30 years in the past.
Younger people will always be more willing to break things and messing around with ancient and unfriendly build/dev does not attract that demographic because why waste time messing around with the build env that actually getting things done.
One day rust will be the same and the process will start again.
If you're on unix, I think the only thing you really need is cc and ld. The build system aims for flexibility instead of each project being its own personal world and things are duplicated ad momentum. Everyone is happy playing in their little sandbox instead of truly collaborating with each other and create great software.
It's an argument for/against doing anything. The question is how large of a change can you get away with. Ubuntu seems to think they can get away with a 1:1 replacement being acceptable by 26.04, I doubt they'd think the same about forcing alternative tooling options just because the impetus is the same.
Improvement to what? It's not like anyone is creating a new paradigm (or even ripping off an old one, like smalltalk or plan9). It's mostly coming up with a different defaults.
I find this tends to stem from libraries refusing to declare 1.0 for fear it would lock them into bad decisions, not from being unstable. Chrono is a great example: v0.4 for EIGHT YEARS while they make sure the design and APIs are worthy of being set into stone as 1.0 (think: Stability Bit Versioning).
Sure, some pre-1.0 libraries in Rust land are actually wildly volatile, but I find that's not especially the norm, out of the crates I've used. That said... 0.4 for EIGHT YEARS is also a pretty darn good sign you've solidified the API by now, and should probably just tag a 1.0 finally...
I'm not "furious", but I do think your comment was bad and deserved to be downvoted. You're posting a random opinion with nothing to back it up, which is, to boot, factually wrong.
Was there something wrong with the old coreutils that needed improvement?
I have a suspicion it's about the license, like this commenter [0] did a year ago.
[0]: https://news.ycombinator.com/item?id=38853429
Agreed. Since GNU Coreutils is GPLv3 but uutils is MIT, my guess is eventually Canonical will start using "works like the GNU software except you don't have to comply with GPLv3" as a selling point for Ubuntu Core (their IoT focused distro). This would let them sell to companies who want to only permit signed firmware images to run on their devices, which isn't allowed under GPLv3.
If that's really the case, I wish they would just come out and say it and spare the rest of us the burden of trying to debate such a decision on its technical merits. (Of course, I am aware that they owe me nothing here.)
Assuming this theory is true then, what other GPLv3-licensed "core" software in the distro could be next on their list?
If it was only for that, they could use/improve busybox, which has the same license as the kernel (GPLv2).
Perhaps it is also so they can be used in closed source systems (I have uutils installed on my Windows system which works nicely).
Busybox is frankly a horrible user experience, and will never be a good one. Its niche is to be as small as possible, as a single static executable, while providing most tools you need to get the job done in an embedded system. Bells and whistles like a shell that's nice to use, or a vi implementation with working undo/redo, or extensive built-in documentation in the form of --help output, are non-features which would make busybox worse for its primary use case.
Search for "Tivoization" and the GPLv3
Isn't preventing "tivoization" the whole point of the GPLv3?
The authors have specifically said that it’s not. They just chose Rust community licensing norms, they don’t really care about licenses.
I like how the first comment is asking "is anyone actually going to switch to this version?" and here we are with one of the major Linux distributions using it already, and already managed to ship a bug via it.
Brave of them to ship a Rust port of sudo as well.
It looks like we have three major open source imementations:
- GNU coreutils (GPLv3)
- uutils coreutils (MIT)
- busybox (GPLv2)
There's the BSD coreutils too.
I've had the same suspicion since I read about it the first time.
Is it not just yet another Rust rewrite?
Probably stuff like https://www.cvedetails.com/cve/CVE-2015-4042/
It wasn’t… “safe”
It seems like I'm probably preaching to the choir, but what really is the attack surface with coreutils? I can't imagine there have been a lot of pwns as a result of the `date` command.
Untrusted input is often stored in files. Coreutils tools are often used to operate on those files.
As an obvious example, I sometimes download files from the Internet, then run coreutils sha256sum or the like on those files to verify that they're trustworthy. That means they're untrusted at the time where I use them as input to sha256sum.
If there's an RCE in sha256sum (unlikely, but this is a thought experiment to demonstrate an attack vector), then that untrusted file can just exploit that RCE directly.
If there's a bug in sha256sum which allows a malicious file to manipulate the result, then a malicious file could potentially make itself look like a trusted file and therefore get past a security barrier.
Maybe there's no bug in sha256sum, but I need to base64 decode the file before running sha256sum on it, using the base64 tool from coreutils.
If you use your imagination, I'm sure you yourself can think up plenty more use cases where you might run a program from GNU coreutils against untrusted user input. If it helps, here's a Wikipedia article which lists all commands from GNU coreutils: https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands
EDIT: To be clear, this comment is only intended to explain what the attack surface is, not to weigh in on whether rewriting the tools in Rust improves security. One could argue that it's more likely that the freshly rewritten sha256sum from uutils has a bug than that GNU sha256sum has a bug. The statement "tools from coreutils are sometimes used to operate on untrusted input and therefore have an attack surface worth exploring" is not the same as the statement "rewriting coreutils in Rust improves security". Personally, I'm excited for the uutils stuff, but not primarily because I believe it alone will directly result in significant security improvements in Ubuntu 25.10.
To play devil's advocate, who knows what kind of madness people are handing off to subprocess.run(["date"]) et al. They shouldn't, but I'd bet my last dollar it's out there.
I can certainly understand it for something like sudo or for other tools where the attack surface is larger and certain security-critical interactions are happening, but in this case it really seems like a questionable tradeoff, where the benefits in this specific case are abstract (theoretically no more possibility of any memory-safety bugs) but the costs are very concrete (incompatibility issues; and possibly other, new, non-memory-safety bugs being introduced with new code).
EDIT: Just to be clear, I'm otherwise perfectly happy that these experiments are being done, and we should all be better off for it and learn something as a result. Obviously somebody has assessed that this tradeoff has at least a decent probability of being a net positive here in some timeframe, and if others are unhappy about it then I suppose they're welcome to install another implementation of coreutils, or use a different distro, or write their own, or whatever.
> "sudo"
Hence "doas".
OpenBSD has a lot of new stuff throughout the codebase.
No need for adding a bloated dependency (e.g. Rust) just because you want to re-implement "yes" in a "memory-safe language" when you probably have no reasons to.
You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way.
Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old.
See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.
> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.
The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected.
Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.
> didn't throw errors, it would just send a warning to standard error
Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams.
> Those commands were never standardized
"Those commands" were present in v7 unix in 1979!
and yet coreutils continues to receive updates in ways that could break things.
I reported a segfault in "tac" a number of years ago.
when your bug it fully typed
Safer threading for performance improvements was part of it, as I understand.
If you're the maintainer of OpenBSD, then implementing coreutils in a given language is a necessary requirement for it to be considered a viable systems language: https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
This should give you the necessary background
https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
I think it's mainly that it's a fun project and Rust is a lot nicer to work with than C. You're way more likely to see modern niceties and UX improvements in these ones than the old ones.
> Rust is a lot nicer to work with than C
What? How??
no, just the usual... people want to rewrite stuff in Rust "just because". it's getting annoying.
Other people are allowed to do whatever they want.
It wasn't rewritten in rust yet. Therefore it wasn't complete. /s
Not enough Rust.
The thought of rewriting anything as intricate, foundational, and battle-tested as GNU coreutils from scratch scares me. Maybe I'd try it with a mature automatic C-to-Rust translator, but I would still expect years of incompatibilities and reintroduced bugs.
See also the "cascade of attention-deficit teenagers" development model.
FWIW, GNU coreutils is itself a rewrite of stuff that existed before, and which has been rewritten multiple other times.
Eh. People have written replacements for glibc because they didn't like something or another about it, and that seems to me to be way more fraught with risk than coreutils.
Folks also run into compatibility issues with musl as well. The biggest I recall was an issue with DNS breaking because musl didn’t implement some piece.
Fair enough. My gut sense is that C functions are simpler than shell commands, with a handful of parameters rather than a dozen or more flags, and this bug supports that -- they forgot to implement a flag in "date." But I haven't tried to do either, so I could be wrong.
Anyone have a link to the patch in uutils? Curious to see that the problem and solution were.
This comment[0] explains it.
The core bug seems to be that support for `date -r <file>` wasn't implemented at the time ubuntu integrated it [1, 2].
And the command silently accepted -r before and did nothing (!)
0: https://lwn.net/Articles/1043123/
1: https://github.com/uutils/coreutils/issues/8621
2: https://github.com/uutils/coreutils/pull/8630
This doesn't look like a bug, that is, something overlooked in the logic. This seems like a deliberately introduced regression. Accepting an option and ignoring it is a deliberate action, and not crashing with an error message when an unsupported option is passed must be a deliberate, and wrong, decision.
It's wrong (and coreutils get it right) but I don't see why it would have to be deliberate. It could easily just not occur to someone that the code needs to be tested with invalid options, or that it needs to handle invalid options by aborting rather than ignoring. (That in turn would depend on the crate they're using for argument parsing, I imagine.)
Could parsing the `-r` be added without noticing it somehow?
If it was added in bulk, with many other still unsupported option names, why does the program not crash loudly if any such option is used?
A fencepost error is a bug. A double-free is a bug. Accepting an unsupported option and silently ignoring it is not, it takes a deliberate and obviously wrong action.
It certainly doesn't look intentional to me- it looks like at some point someone added "-r" as a valid option, but until this surfaced as a bug, no one actually implemented anything for it (and the logic happens to fall through to using the current date).
> deliberately introduced regression
> deliberate and wrong decision
Yeah... I hope "we" will not switch to it just because it is written in Rust. There is much more than just the damn language behind it.
I would say that Canonical is more at fault in this case.
I'm frankly appalled that an essential feature such as system updates didn't have an automated test that would catch this issue immediately after uutils was integrated.
Nevermind the fact that this entire replacement of coreutils is done purely out of financial and political rather than technical reasons, and that they're willing to treat their users as guinea pigs. Despicable.
What surprises me is that the job seems rushed. Implementation is incomplete. Testing seems patchy. Things are released seemingly in a hurry, as if meeting a particular deadline was more important for the engineers or managers of a particular department than the qualify of the product as a whole.
This feels like a large corporation, in the bad sense.
This seems to be the Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
It would be really nice if something said what the actual problem was.
The last commit[0] is a fix for date parsing to bring it in line with the GNU semantics, which seems like a pretty good candidate.
Edit: Or not, see evil-olive's comment[1] for a more likely candidate.
0: https://github.com/uutils/coreutils/commit/0047c7e66ffb57971...
1: https://news.ycombinator.com/item?id=45687743
https://lists.ubuntu.com/archives/ubuntu-security-announce/2...
A classic
annoyingly, they don't link to the actual bug in question, just say:
> Systems with the rust-coreutils package version 0.2.2-0ubuntu2 or earlier have the bug, it is fixed in 0.2.2-0ubuntu2.1 or later.
based on the changelog [0] it seems to be:
> date: use reference file (LP: #2127970)
from there: [1]
> This is fixed upstream in 88a7fa7adfa048dabdffc99451d7aba1d9e6a9b6
which in turn leads to [2, 3]
> Display the date and time of the last modification of file, instead of the current date and time.
this is not the type of bug I was expecting, I assumed it would be something related to a subtle timezone edge case or whatever.
instead, `date -r` is supposed to print the modtime of a given file:
and it seems like the Rust version just...silently ignored that expected behavior?maybe I'm missing something? if not this seems really sloppy and not at all what I'd expect from a project aiming to replace coreutils with "safer" versions.
0: https://launchpad.net/ubuntu/questing/+source/rust-coreutils...
1: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
2: https://github.com/uutils/coreutils/issues/8621
3: https://github.com/uutils/coreutils/pull/8630
It's supposed to pass the coreutils upstream tests. If it does, then that would mean the upstream tests still need work
It... doesn't though: https://uutils.github.io/coreutils/docs/test_coverage.html
Neither this issue, which doesn't appear to be a bug at all but merely an unimplemented feature, nor the fact that uutils doesn't (yet) pass the entire testsuite, seem to me to at all be an indictment of the uutils project, merely a sign that it is incomplete. Which is hardly surprising when I get the impression it's primarily been a hobby project for a bunch of different developers. It does make me wonder about the wisdom of Ubuntu moving to it.
If it's not passing the test suite, then why is it even considered for inclusion in a distribution like Ubuntu?
Ubuntu is likely used by 10s of millions of servers and desktops. I'm not sure why this kind of breakage is considered acceptable. Very confusing.
It's a part of Ubuntu 25.10 to get it ready for prime time for Ubuntu 26.04.
Users who need stability should use the LTS releases. The interim releases have always been more experimental, and have always been where Canonical introduces the big changes to ensure everything's mature by the time the LTS comes around.
Maybe the thought is that there will be more pressure now on getting all the tests to pass given the larger install base? It isn't a great way to push out software, but it's certainly a way to provide motivation. I'm personally more interested in whether the ultimate decision will be to leave these as the default coreutils implementation in the next Ubuntu LTS release version (26.04) or if they will switch back (and for what reason).
100% agree. Why would they adopt it if it doesn't pass the upstream test suite. I assumed that would be required before even considering it!
I was expecting that they would be concerned about bugs in the untested parts!
> If it's not passing the test suite, then why is it even considered for inclusion in a distribution like Ubuntu?
Because "Rust". Sad, but true.
they have a tendency to try novel/different things, like upstart (init system), mir (desktop compositor (?))
and this is probably a net positive, there's now an early adopter for the project, the testsuite gets improved, and the next Ubuntu LTS will ship more modern tools
FWIW, the first test in the coreutils test suite covering the `date -r` case was added... 5 hours ago: https://github.com/coreutils/coreutils/blob/master/tests/dat...
I don't know what the code coverage of coreutils' test suite is, but my guess is that it's not spectacular.
Wow. Maybe I'm missing something but it seems really weird to replace a tool with a rewrite that doesn't pass the test suite!
I mean, how long did they take to realize that the more(1) they shipped had no equivalent in GNU coreutils at all? Its from util-linux: https://github.com/uutils/coreutils/issues/8975
Doesn't look like people who do their homework
yeah, based on some more digging, it looks like a test case for `date --reference` in GNU coreutils was only added a few hours ago [0] so I assume it was in response to this bug.
but I don't think that should let the uutils authors off the hook - if `--reference` wasn't implemented, that should have been an error rather than silently doing the wrong thing.
after even more Git spelunking, it looks like that problem goes all the way back to the initial "Partial implemantion of date" [1] commit from 2017 - it included support for `--reference` in the argument parsing, including the correct help text, but didn't do anything with it, not even a "TODO: Handle this option" comment like `--set` has.
0: https://github.com/coreutils/coreutils/commit/14d24f7a530f58...
1: https://github.com/uutils/coreutils/commit/41d1dfaf440eabba3...
https://github.com/coreutils/coreutils/commit/14d24f7a5
That bring GNU date(1) line coverage from 79.8% to 87.1%
There were no buffer overflows, though!
I also can't be hacked if I pull the power to my PC!
The rewrite has NOTHING to do with security and is all about licensing. coreutils are GLPv3 rust-coreutils are MIT
So what? Standalone binaries don't infect other things with copyleft anyway.
Is that true? If I make a product, and that product runs some embedded Linux system with GPLv3-licensed coreutils, are you confident that my product isn't infected by GPLv3?
Canonical is trying to position Ubuntu as a relevant player in the embedded space.
This hasn't stopped anybody from releasing a product that I'm aware of.
Apple never upgraded to GPL3 coreutils, bash and remained away from anything GPL3…
Oh, you mean specifically GPL v3 license, not any GPL license.
Yeah, broad tivoisation and patent clauses make it a problem, because making any patent litigation on unrelated grounds has potential to lose ability to ship the entire OS.
There is a lot of FUD spread about GPL so companies tend to just nope out entirely.
Can we just go back to the real version?
debian-stable welcomes you
I think this is where I'm going after a good 15 years with Ubuntu.
They've lost the plot. I don't mind change if it has meaningful benefits, but forcing unstable and barely-tested coreutils is madness.
> But seriously. Rewriting C utilities that have been battle-tested for decades in Rust might be a good idea in the long term, but anyone could have predicted short-term hiccups.
How "long term" are we talking about that rewriting battle-tested, mission-critical C utils (which, as other posters noted, in this case often have minimal attack surfaces) actually makes sense?
>> Which is why I'm glad they're doing it! It seems like the kind of thing that one can be understandably scared to ever do, and I say this as one of the folks involved with getting some Rust in the Linux kernel.
Total zealot.
Reminder that one of the uutils devs gave a talk at FOSDEM where he used spurious benchmarks to falsely claim uutils's sort was faster, only for /g/ users to discover it was only because it was locale-unaware, and in fact was much slower:
https://archive.fosdem.org/2025/schedule/event/fosdem-2025-6... (~15 min)
https://desuarchive.org/g/thread/104831348/#q104831479
https://desuarchive.org/g/thread/104831348/#104831809
> How "long term" are we talking about that rewriting battle-tested, mission-critical C utils (which, as other posters noted, in this case often have minimal attack surfaces) actually makes sense?
Makes me wonder if putting a similar amount of effort into building up proof/formal verification system for coreutils would have yielded better results security wise.
That's why it's called the bleeding edge. Rust dev culture is 99% bleeding edge. It is not a culture of stability. It is a culture of change and the latest and greatest. The language could be used in stable ways, but right now, it's not.
That's one heck of an extrapolation from one incident, or even one project, in a language that has been post-1.0 for a decade and has a wide variety of users with a wide variety of update/upgrade preferences and subcultures.
I agree, but the post does resonate - Rust still has a very "Ready to make breaking changes on a whim" reputation
Which makes sense because in 2025 people have grown tired of lack of improvement so that some esoteric ass compiler from the 90s still works or someones 30 year old bash script still functions.
Pros and Cons either way for better or worse depending on your perspective.
I've largely lost patience with the current culture of sacrificing any backwards compatibility that is slightly inconvenient in the name of “improvement”.
That’s an argument against creating uuutils; it is a project that aims for coreutils 100% compatibility. eza, bat, ripgrep, etc are more exciting for at least having different features than coreutils
I was more commenting on the Rust community being ready to make breaking changes.
Personally while I think Rust is a decent language it would not have caught on with younger devs if C/C++ didn't have such a shitty devex that is stuck 30 years in the past.
Younger people will always be more willing to break things and messing around with ancient and unfriendly build/dev does not attract that demographic because why waste time messing around with the build env that actually getting things done.
One day rust will be the same and the process will start again.
If you're on unix, I think the only thing you really need is cc and ld. The build system aims for flexibility instead of each project being its own personal world and things are duplicated ad momentum. Everyone is happy playing in their little sandbox instead of truly collaborating with each other and create great software.
It's an argument for/against doing anything. The question is how large of a change can you get away with. Ubuntu seems to think they can get away with a 1:1 replacement being acceptable by 26.04, I doubt they'd think the same about forcing alternative tooling options just because the impetus is the same.
Improvement to what? It's not like anyone is creating a new paradigm (or even ripping off an old one, like smalltalk or plan9). It's mostly coming up with a different defaults.
> Rust still has a very "Ready to make breaking changes on a whim" reputation
No it doesn't. What on earth are you talking about?
I like Rust, but almost all libraries I end up using are on some 0.x version...
I find this tends to stem from libraries refusing to declare 1.0 for fear it would lock them into bad decisions, not from being unstable. Chrono is a great example: v0.4 for EIGHT YEARS while they make sure the design and APIs are worthy of being set into stone as 1.0 (think: Stability Bit Versioning).
Sure, some pre-1.0 libraries in Rust land are actually wildly volatile, but I find that's not especially the norm, out of the crates I've used. That said... 0.4 for EIGHT YEARS is also a pretty darn good sign you've solidified the API by now, and should probably just tag a 1.0 finally...
As is the norm for HN and Rust commentary - any slight criticism is met with fury and downvotes.
Yeah, sweeping hot takes with very little to back them up do tend to get downvoted.
More than anything, the Rust community is hyper-fixated on stability and correctness. It is very much the antithesis to “move fast and break things”.
Which would be borne out with discourse, not hate - but you do you
I'm not "furious", but I do think your comment was bad and deserved to be downvoted. You're posting a random opinion with nothing to back it up, which is, to boot, factually wrong.
What breaking changes has Rust made "on a whim" ?
All day every day I see "random opinion with nothing to back it up" posts on Hacker News, but are not voted down - discuss.
> Rewrite in rust so it will have no bugs
You promised!
Nobody promised that. Please don't make things up.
It would be silly to do so, for sure.