LWN: Comments on "Date bug affects Ubuntu 25.10 automatic updates"

The next Ubuntu release...

rahulsundaram — Fri, 24 Oct 2025 15:02:28 +0000

> I blame Canonical for precipitating a second "We told you KDE 4.0 was a developer preview, not an end-user release" situation.

I don't see anything in the KDE 4 announcement to indicate that it was a developer preview. Where is this coming from?

uutils is doing well, but needs to be carefully managed

pixelbeat — Fri, 24 Oct 2025 14:58:28 +0000

Ah right. Note the default GNU coreutils setup avoids that issue by using a wrapper script rather than symlinks. That's the default behavior with ./configure --enable-single-binary in GNU coreutils. I.e. it would install a file with the following contents at /usr/bin/true

#!/usr/bin/coreutils --coreutils-prog-shebang=true

The next Ubuntu release...

ssokolow — Fri, 24 Oct 2025 13:56:41 +0000

And yet I don't think that's how it would go for two reasons:

uutils began as a pile of practice projects, not a minmax'd effort to produce a 1-to-1 replacement the most efficient way possible
They already know that it doesn't pass the full GNU coreutils test suite yet.

I blame Canonical for precipitating a second "We told you KDE 4.0 was a developer preview, not an end-user release" situation.

uutils has more overhead

pixelbeat — Fri, 24 Oct 2025 13:55:34 +0000

Yes agreed, though it's a different decision with uutils as the separate binaries are significantly larger.

Note also that GNU coreutils can be built as a multi-call binary. Testing the performance of that here shows that the overhead is not rust specific, but rather the dynamic linker overhead loading the full set of libs linked by the multi-call binaries

$ ./configure --enable-single-binary --quiet && make -n $(nproc)

$ time seq 10000 | xargs -n1 src/true

real	0m21.595s
user	0m7.437s
sys	0m14.151s

uutils has more overhead

ebee_matteo — Fri, 24 Oct 2025 13:41:43 +0000

From https://github.com/uutils/coreutils:

> If you don't want to build the multicall binary and would prefer to build the utilities as individual binaries, that is also possible.

This is a decision from the distribution to take, I would say.

uutils is doing well, but needs to be carefully managed

juliank — Fri, 24 Oct 2025 13:31:42 +0000

Yes, a bunch of things disabled some scripts in .d directories by creating symlinks to /bin/true in their place.

Because we dispatch by argv[0] in the multi-call binary we then did not find the binary because the tool was invoked with the symlink name.

We do have a hardlink farm now and can resolve based on hardlink where available but it's a bit messy because it requires /proc to be mounted.

The next Ubuntu release...

dralley — Fri, 24 Oct 2025 13:25:20 +0000

There is a net benefit in getting embedded device code written in a language with less security issues (not that coreutils is a significant culprit). I wouldn't be upset at all if embedded devices used it.

Don't fix what aint broke

LtWorf — Fri, 24 Oct 2025 13:14:41 +0000

Not only C is still there. Job offers in C outnumber the job offers in Rust (at least in my area).

The next Ubuntu release...

joib — Fri, 24 Oct 2025 12:13:17 +0000

There's already toybox as a BSD-licensed busybox clone, used e.g. in android. And of course all the BSD's have their own versions of the core utilities. So for better or worse, that ship as truly sailed I think.

uutils is doing well, but needs to be carefully managed

makapuf — Fri, 24 Oct 2025 11:31:02 +0000

Yes, this will allow easy feature testing with test true == false

The next Ubuntu release...

ballombe — Fri, 24 Oct 2025 11:10:33 +0000

> But that's a whole other debate...
It is not an other debate. This bug is a direct consequence of this decision.
If they were willing to be a GNU GPL derivative of the original coreutils, they could port the C code to rust instead of rewriting it from first principle, which would avoid introduce fresh bugs.

uutils has more overhead

pixelbeat — Fri, 24 Oct 2025 11:09:31 +0000

Interesting, I hadn't realized /bin/true was still GNU. Perhaps this is a performance consideration, as all uutils have a larger startup overhead than their GNU equivalents, due mainly to the large multicall binary being used (due to rust binaries being significantly larger). For example:

$ time seq 10000 | xargs -n1 true
real	0m8.634s
user	0m3.178s
sys	0m5.616s

$ time seq 10000 | xargs -n1 uu_true
real	0m22.137s
user	0m6.542s
sys	0m15.561s

It irks me to see mention of rust implementations being faster, when at a fundamental level like this they're slower and add significant overhead to every command run

uutils is not doing well

collinfunk — Fri, 24 Oct 2025 10:18:23 +0000

Well, GNU true returns non-zero in some cases. :)

$ /bin/true; echo $?
0
$ /bin/true --help > /dev/full; echo $?
true: write error: No space left on device
1

uutils is not doing well

jengelh — Fri, 24 Oct 2025 09:27:16 +0000

>/usr/bin/false is a symlink to the Rust version, but /usr/bin/true is a symlink to the GNU C version

uutils-md5sum was recently broken too[1], so it is only natural to make a sensitive program like /bin/true (only one very specific return value is allowed!) be based on a known-good implementation.

[1] https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Make...

uutils date bug timeline and root cause

cyperpunks — Fri, 24 Oct 2025 09:19:57 +0000

uutils has been implemented without creating a robust and solid option parser first?

Don't fix what aint broke

alx.manpages — Fri, 24 Oct 2025 08:48:46 +0000

> As for C not disappearing, it feels like we are already in an era where most young people below the age of 35-40 or so do not learn it any more

I'm 32, and I went to university with people 7 years younger than me, and C was still the main language we studied there.

I've heard that some schools have reduced the amount of C courses, but it's still there.

> so you might be surprised how quickly the pool of potential volunteer maintainers will deplete for boring, mature C projects.

While the number of people knowing C enough might reduce, it might also increase the ratio of C programmers that know C very well. Self-selection can be a good thing. I don't expect the amount of C experts to diminish significantly.

> These tools need maintenance and rewriting them in something with a saner build system than C has to offer after being around for 50 years certainly will make this easier.

C has evolved quite a lot in these 50 years, and I'm not sure Rust is better than C. Most of the issues people complain about C are in reality issues with old C, or low quality compilers. Some issues remain in the latest GCC, but there's work on having an even better C in the following years.

Incremental improvements are better than entirely jumping to a new language, and this issue with Rust's date(1) is an example of why we should keep improving the C version, which is almost bug-free, instead of writing bugs in a different language.

<https://www.joelonsoftware.com/2000/04/06/things-you-shou...>

The next Ubuntu release...

leromarinvit — Fri, 24 Oct 2025 08:46:06 +0000

It takes away one possible avenue to try and get vendors to release embedded firmware source code. Much like Busybox probably isn't particularly monetizable, but it has been used successfully to get vendors to release sources - including e.g. custom kernel patches that are much more interesting than Busybox itself.

uutils date bug timeline and root cause

taladar — Fri, 24 Oct 2025 07:49:02 +0000

If they had used to clap derive way of specifying arguments it would likely have been caught as an unused case but presumably that wasn't an option to stay compatible with the old interface behavior exactly.

Don't fix what aint broke

taladar — Fri, 24 Oct 2025 07:40:17 +0000

If they are done then why are there so many commits in the repo that the short version on

https://gitweb.git.savannah.gnu.org/gitweb/?p=coreutils.git

showing the last 16 commits doesn't even go back a week of development history?

These tools need maintenance and rewriting them in something with a saner build system than C has to offer after being around for 50 years certainly will make this easier.

As for C not disappearing, it feels like we are already in an era where most young people below the age of 35-40 or so do not learn it any more so you might be surprised how quickly the pool of potential volunteer maintainers will deplete for boring, mature C projects.

Don't fix what aint broke

eru — Fri, 24 Oct 2025 06:30:16 +0000

Rewriting C utilities that have been battle-tested for decades in Rust might be a good idea in the long term,

I fail to see why it would be a good idea even in the long term. These utilities are done, the specifications do not change, or change very little. The only valid reason might be a future situation, where support for the C language starts disappearing, which is totally a fantasy scenario. C is too entrenched for that to happen within the expected lifetime of our technical civilisation.

uutils is doing well, but needs to be carefully managed

mb — Fri, 24 Oct 2025 06:05:38 +0000

Rust is not the one and only truth, yet.

uutils is doing well, but needs to be carefully managed

Keith.S.Thompson — Fri, 24 Oct 2025 04:04:08 +0000

Oddly, /usr/bin/false is a symlink to the Rust version, but /usr/bin/true is a symlink to the GNU C version.

I wonder whether that was a deliberate decision.

("true" and "false" are bash builtins, so the commands under /usr/bin probably aren't used very often.)

The next Ubuntu release...

welinder — Fri, 24 Oct 2025 01:45:59 +0000

Agreed. And it's not even that the C versions are bug free -- probably not, but who knows? -- but that whatever bugs there might exist have been adapted to. New code, new bugs.

And it's humbling to see that a silly little bug deep in date can silently break unattended security updates!

The next Ubuntu release...

dralley — Thu, 23 Oct 2025 23:57:34 +0000

I don't think software like the coreutils is particularly monetizable these days. Especially if the whole point of it is to behave exactly the same as existing software. Meh.

uutils is doing well, but needs to be carefully managed

csigler — Thu, 23 Oct 2025 23:26:22 +0000

> I wish them well, but this needs to be carefully managed.

I cannot possibly (imaginarily) upvote this comment enough.

For those familiar with the 1976 movie "Network":

"You have meddled with the primal forces of Unix, and _you_will_atone_!!!"

Clemmitt

The next Ubuntu release...

dskoll — Thu, 23 Oct 2025 22:21:58 +0000

I don't have anything against Rust (nor against C), but I do think it's unfortunate that the Rust utilities are licensed under the MIT license rather than the GPL. But that's a whole other debate...

uutils date bug timeline and root cause

geofft — Thu, 23 Oct 2025 22:00:09 +0000

I think it would be interesting for Ubuntu to do (at some point, not right this second) an incident report / postmortem on how this happened.

Looks like this was originally reported in https://pad.lv/2127970 on October 16, exactly one week ago and also exactly one week after Ubuntu 25.10's release. The reporter originally mentioned the bug in the context of a homegrown backup script that was failing silently, and they got the fix into the proposed stable update repository yesterday, with an (understandable) argument about why it wasn't same-day levels of urgent.

This morning, someone pointed out that it breaks unattended-upgrades. It seems to me that it was only at this point that it was tracked as a security issue, and the package is now available in both the (prod) stable updates repository and the more minimal security updates repository.

The actual bug itself is simply that support for `date -r <file>` wasn't implemented. The issue https://github.com/uutils/coreutils/issues/8621 and the pull request implementing support https://github.com/uutils/coreutils/pull/8630 were both filed on the same day, September 12 of this year, and it was reviewed and merged into main two days later. This, understandably, postdates whichever release Ubuntu snapshotted.

I think I am mostly surprised that the command silently accepted -r and did nothing, and indeed from the actual diff (https://github.com/uutils/coreutils/commit/88a7fa7adfa048...) it's pretty clear that the argument parser had support for it but it wasn't wired up to do anything. If the command had instead returned an argument parsing error, I think this would have been caught a lot quicker. It does seem a little bit odd that whoever implemented this in the argument parser didn't at least add an "if -r, throw 'todo'" case. But it's also interesting that this was not statically caught. The Rust compiler is pretty good at warning and complaining about unused variables. (To be fair, most C compilers and many other languages are too, though anecdotally these warnings seem less noisy in Rust and I've seen more codebases in Rust where this is a hard failure than C codebases using -Werror. Also, Rust has #[must_use], if you want to be thorough.) However, there wasn't actually an unused variable here; you can see that you get the value out of the parsed-arguments object by asking for the value of the flag.

I wonder if it's worth thinking about an argument-parsing API in Rust that would raise an unused-variable warning at compile time if a parsed command-line flag or argument is never used in the code. It might also be possible to do this with the existing parser with a sufficiently clever linter. Either way, the lack of compile-time detection of this bug feels at odds with the philosophy of a Rust rewrite of coreutils, i.e., that there's merit in having tools do the checking instead of trusting and expecting people to write perfect code.

I also think it would be very much worth it for Ubuntu and the uutils developers to manually do an audit for all arguments that are parsed in an argument parser but not actually implemented. If this pattern happened once, it likely isn't the only case.

The next Ubuntu release...

geofft — Thu, 23 Oct 2025 21:38:31 +0000

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.

No problems for oldschool Linux users ...

JMB — Thu, 23 Oct 2025 21:35:12 +0000

It is interesting that it seems that automatic updates are of high priority.
For Smartphone Junkies that may be true (due to fear of missing out),
but for experts there is no need to get even security fixes in less than a week.

And concerning servers ... in most cases even extreme security relevant problems
are not fixed due to other priorities anyway ... form frozen zone ... to ice age.

At least the problem shows that it is not fuitile to have tested the new Rust code ...
but still wondering if concerning all bugs Rust really have a positive benefit
for experienced coders ... seems more a hype than something which can be prooved.

uutils is doing well, but needs to be carefully managed

pixelbeat — Thu, 23 Oct 2025 21:12:28 +0000

Note ubuntu 25.10 is still using GNU for the "scary" commands like cp, mv, rm, ... They should rip that band aid off sooner rather than later, so that any data corruption possibilities are identified before ubuntu 25.10 becomes more established or the next LTS release becomes imminent. Copying a file on unix has lots of edge cases multiplied by various file sytems and even kernel bugs etc.

Then there are fundamental issues with SIGPIPE handling in all the uutils https://github.com/uutils/coreutils/issues/8919

Also there are questionable interface changes being added like 12 ways to get a sha3 https://github.com/uutils/coreutils/issues/8984

I wish them well, but this needs to be carefully managed.

The next Ubuntu release...

dskoll — Thu, 23 Oct 2025 20:52:03 +0000

... will be called Grateful Guinea-Pig

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.