Date bug in Rust-based coreutils affects Ubuntu 25.10 automatic updates
100 comments
·October 23, 2025trollbridge
rolandog
I have a suspicion it's about the license, like this commenter [0] did a year ago.
ndiddy
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.
ls65536
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?
mjmas
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).
easterncalculus
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.
steveklabnik
The authors have specifically said that it’s not. They just chose Rust community licensing norms, they don’t really care about licenses.
CaptainOfCoit
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.
mjmas
It looks like we have three major open source imementations:
- GNU coreutils (GPLv3)
- uutils coreutils (MIT)
- busybox (GPLv2)
skydhash
There's the BSD coreutils too.
LtWorf
I've had the same suspicion since I read about it the first time.
johnisgood
Is it not just yet another Rust rewrite?
dwroberts
Probably stuff like https://www.cvedetails.com/cve/CVE-2015-4042/
jcranmer
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
bn-l
It wasn’t… “safe”
throitallaway
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.
mort96
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.
denkmoon
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.
ls65536
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.
ajross
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.
LtWorf
I reported a segfault in "tac" a number of years ago.
agumonkey
when your bug it fully typed
jwhitlark
Safer threading for performance improvements was part of it, as I understand.
tecoholic
This should give you the necessary background
https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
IshKebab
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.
bilekas
It wasn't rewritten in rust yet. Therefore it wasn't complete. /s
username223
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.
umanwizard
FWIW, GNU coreutils is itself a rewrite of stuff that existed before, and which has been rewritten multiple other times.
kstrauser
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.
elcritch
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.
username223
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.
jey
Anyone have a link to the patch in uutils? Curious to see that the problem and solution were.
cataflam
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/
nine_k
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.
none_to_remain
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).
zahlman
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.)
johnisgood
> 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.
imiric
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.
pedrocr
This seems to be the Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
janzer
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...
evil-olive
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
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...
johnny22
It's supposed to pass the coreutils upstream tests. If it does, then that would mean the upstream tests still need work
gpm
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.
e2le
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.
jcranmer
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.
cataflam
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!
blueflow
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
evil-olive
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...
pixelbeat__
https://github.com/coreutils/coreutils/commit/14d24f7a5
That bring GNU date(1) line coverage from 79.8% to 87.1%
none_to_remain
There were no buffer overflows, though!
throitallaway
I also can't be hacked if I pull the power to my PC!
IlikeKitties
The rewrite has NOTHING to do with security and is all about licensing. coreutils are GLPv3 rust-coreutils are MIT
Ginden
So what? Standalone binaries don't infect other things with copyleft anyway.
mort96
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.
johnny22
This hasn't stopped anybody from releasing a product that I'm aware of.
LtWorf
Apple never upgraded to GPL3 coreutils, bash and remained away from anything GPL3…
Ginden
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.
yoyohello13
There is a lot of FUD spread about GPL so companies tend to just nope out entirely.
anonnon
> 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)
elcritch
> 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.
wartywhoa23
[flagged]
superkuh
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.
klardotsh
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.
awesome_dude
I agree, but the post does resonate - Rust still has a very "Ready to make breaking changes on a whim" reputation
tempest_
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.
umanwizard
> 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?
awesome_dude
As is the norm for HN and Rust commentary - any slight criticism is met with fury and downvotes.
matt3210
> Rewrite in rust so it will have no bugs
You promised!
IshKebab
Nobody promised that. Please don't make things up.
johnisgood
It would be silly to do so, for sure.
null
Was there something wrong with the old coreutils that needed improvement?