https://lwn.net/Articles/1043103/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us [INS::INS] User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account Date bug affects Ubuntu 25.10 automatic updates [Posted October 23, 2025 by jzb] The Ubuntu Project has announced that a bug in the Rust-based uutils version of the date command shipped with Ubuntu 25.10 broke automatic updates: Some Ubuntu 25.10 systems have been unable to automatically check for available software updates. Affected machines include cloud deployments, container images, Ubuntu Desktop and Ubuntu Server installs. The announcement includes remediation instructions for those affected by the bug. 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. It does not impact manual updates using the apt command or other utilities. Ubuntu embarked on a project to "oxidize" the distribution by switching to uutils and sudo-rs for the 25.10 release, and to see if the Rust-based utilities would be suitable for the long-term-release slated for next April. LWN covered that project in March. ----------------------------------------- [Log in] to post comments The next Ubuntu release... Posted Oct 23, 2025 20:52 UTC (Thu) by dskoll (subscriber, #1630) [ Link] (16 responses) ... 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. [Reply to this comment] The next Ubuntu release... Posted Oct 23, 2025 21:38 UTC (Thu) by geofft (subscriber, #59789) [ Link] (10 responses) 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. [Reply to this comment] The next Ubuntu release... Posted Oct 23, 2025 22:21 UTC (Thu) by dskoll (subscriber, #1630) [ Link] (9 responses) 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... [Reply to this comment] The next Ubuntu release... Posted Oct 23, 2025 23:57 UTC (Thu) by dralley (subscriber, #143766) [Link] (3 responses) 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. [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 8:46 UTC (Fri) by leromarinvit (subscriber, # 56850) [Link] (2 responses) 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. [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 12:13 UTC (Fri) by joib (subscriber, #8541) [Link ] 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. [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 13:25 UTC (Fri) by dralley (subscriber, #143766) [Link] 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. [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 11:10 UTC (Fri) by ballombe (subscriber, #9523) [ Link] (3 responses) > 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. [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 13:56 UTC (Fri) by ssokolow (guest, #94568) [Link ] (2 responses) And yet I don't think that's how it would go for two reasons: 1. 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 2. 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. [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 15:02 UTC (Fri) by rahulsundaram (subscriber, # 21946) [Link] (1 responses) > 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? [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 18:38 UTC (Fri) by elimranianass (subscriber, # 164758) [Link] I think it's due to a 15 (almost 20!) years old game of telephone. It started as "Some comments from some devs at the time stated that distros should wait until point releases" (or something like that) into "KDE 4.0 was actually just a dev preview never intended for end users". But I understand why that happened, the KDE 4.0 release was so controversial, and it led to people from all sides blaming the other side :). [Reply to this comment] Copy-left hasn't worked out how I thought it would Posted Oct 24, 2025 22:37 UTC (Fri) by ras (subscriber, #33059) [Link ] Hasn't it always been like this, to some extent? Even glibc is LGPL rather than GPL. Like you I've always been a fan of the copy-left licences, but in retrospect it didn't go the way I expected when I enthusiastically first adopted them. Sometimes that's because companies just ignore them. For example I was startled to find the tunnelling software distributed with Microsoft's InTune was just repackaged GPL software, which they redistributed with no attribution. Instead they slapped the usual, restrictive MS commercial licence on code they had no rights to whatsoever. I only found out because the Linux version was a container of some sort that didn't work. So I unpacked it, eventually discovered what it was, and was able to replace it with suitably tuned Debian packages that received timely security updates. Apple took the other route, which is to avoid copy-left entirely. Most of the app stores steer you in that direction as well. Either way, copy-left demonstrably didn't force those companies to contribute back. The most annoying example of side-stepping copy-left is perhaps NVidia's kernel modules. I have no idea if it was legal or not and as far as I know it hasn't been tested, but regardless it does demonstrate how ineffective copy-left can be. Meanwhile, other companies have contributed back. Lots of them. That's sometimes because they adopted open source as a marketing technique. But often it's because they have no choice. Open source projects like the kernel, GCC and Rust move at such a fast pace that the effort of carrying the patches is too big, so they post them upstream. In an odd way, who uses copy-left vs permissive licences has turned out to be the opposite of how I naively thought it would. The most enthusiastic uses of the AGPL and it's relatives are commercial users, who are trying to prevent other commercial users from selling their work. In the meantime time, the open source world is gradually moving towards permissive licences. The Rust and the JS ecosystems being prime examples. Neither of those ecosystems seem to suffer from it, as both have enormous amounts of code contributed. [Reply to this comment] The next Ubuntu release... Posted Oct 24, 2025 1:45 UTC (Fri) by welinder (guest, #4699) [Link] 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! [Reply to this comment] Don't fix what aint broke Posted Oct 24, 2025 6:30 UTC (Fri) by eru (subscriber, #2753) [Link] (3 responses) 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. [Reply to this comment] Don't fix what aint broke Posted Oct 24, 2025 7:40 UTC (Fri) by taladar (subscriber, #68407) [ Link] (2 responses) 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. [Reply to this comment] Don't fix what aint broke Posted Oct 24, 2025 8:48 UTC (Fri) by alx.manpages (subscriber, # 145117) [Link] (1 responses) > 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. [Reply to this comment] Don't fix what aint broke Posted Oct 24, 2025 13:14 UTC (Fri) by LtWorf (subscriber, #124958) [ Link] Not only C is still there. Job offers in C outnumber the job offers in Rust (at least in my area). [Reply to this comment] uutils is doing well, but needs to be carefully managed Posted Oct 23, 2025 21:12 UTC (Thu) by pixelbeat (guest, #7440) [Link ] (11 responses) 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. [Reply to this comment] uutils is doing well, but needs to be carefully managed Posted Oct 23, 2025 23:26 UTC (Thu) by csigler (subscriber, #1224) [ Link] > 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 [Reply to this comment] uutils is doing well, but needs to be carefully managed Posted Oct 24, 2025 4:04 UTC (Fri) by Keith.S.Thompson (subscriber, # 133709) [Link] (9 responses) 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.) [Reply to this comment] uutils is doing well, but needs to be carefully managed Posted Oct 24, 2025 6:05 UTC (Fri) by mb (subscriber, #50428) [Link] (1 responses) Rust is not the one and only truth, yet. [Reply to this comment] uutils is doing well, but needs to be carefully managed Posted Oct 24, 2025 11:31 UTC (Fri) by makapuf (subscriber, #125557) [Link] Yes, this will allow easy feature testing with test true == false /s [Reply to this comment] uutils is not doing well Posted Oct 24, 2025 9:27 UTC (Fri) by jengelh (guest, #33263) [Link] (1 responses) >/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... [Reply to this comment] uutils is not doing well Posted Oct 24, 2025 10:18 UTC (Fri) by collinfunk (guest, #169873) [ Link] 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 [Reply to this comment] uutils has more overhead Posted Oct 24, 2025 11:09 UTC (Fri) by pixelbeat (guest, #7440) [Link ] (2 responses) 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 [Reply to this comment] uutils has more overhead Posted Oct 24, 2025 13:41 UTC (Fri) by ebee_matteo (subscriber, # 165284) [Link] (1 responses) 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. [Reply to this comment] uutils has more overhead Posted Oct 24, 2025 13:55 UTC (Fri) by pixelbeat (guest, #7440) [Link ] 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 [Reply to this comment] uutils is doing well, but needs to be carefully managed Posted Oct 24, 2025 13:31 UTC (Fri) by juliank (guest, #45896) [Link] (1 responses) 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. [Reply to this comment] uutils is doing well, but needs to be carefully managed Posted Oct 24, 2025 14:58 UTC (Fri) by pixelbeat (guest, #7440) [Link ] 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 [Reply to this comment] No problems for oldschool Linux users ... Posted Oct 23, 2025 21:35 UTC (Thu) by JMB (guest, #74439) [Link] 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. [Reply to this comment] uutils date bug timeline and root cause Posted Oct 23, 2025 22:00 UTC (Thu) by geofft (subscriber, #59789) [ Link] (3 responses) 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 ` 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. [Reply to this comment] uutils date bug timeline and root cause Posted Oct 24, 2025 7:49 UTC (Fri) by taladar (subscriber, #68407) [ Link] (2 responses) 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. [Reply to this comment] uutils date bug timeline and root cause Posted Oct 24, 2025 9:19 UTC (Fri) by cyperpunks (subscriber, #39406) [Link] uutils has been implemented without creating a robust and solid option parser first? [Reply to this comment] uutils date bug timeline and root cause Posted Oct 24, 2025 19:48 UTC (Fri) by geofft (subscriber, #59789) [ Link] Unfortunately that doesn't seem to be caught, either by the regular compiler or clippy: https://play.rust-lang.org/?version=stable&mode= debug... I guess that from the perspective of the compiler, the struct member is "used" because it's passed off to a macro / the derived Parser implementation assigns to it and otherwise uses it. So the fact that the user code isn't using it isn't alerted on. [Reply to this comment] Load-bearing shell script? Posted Oct 24, 2025 22:17 UTC (Fri) by smcv (subscriber, #53363) [ Link] What I'm wondering is why the automatic updates are relying on `date -r`, and not stat(). Is the automatic update a shell script? (I thought Ubuntu used unattended-upgrades, which is Python with calls into the C++ apt libraries; or for desktops, maybe packagekit, which is C with calls into C++.) [Reply to this comment] [INS::INS] Copyright (c) 2025, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds