[HN Gopher] Date bug in Rust-based coreutils affects Ubuntu 25.1...
___________________________________________________________________
Date bug in Rust-based coreutils affects Ubuntu 25.10 automatic
updates
Author : blueflow
Score : 75 points
Date : 2025-10-23 20:49 UTC (2 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| superkuh wrote:
| 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 wrote:
| 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 wrote:
| I agree, but the post does resonate - Rust still has a very
| "Ready to make breaking changes on a whim" reputation
| tempest_ wrote:
| 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.
| cowsandmilk wrote:
| 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
| tempest_ wrote:
| 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.
| zamadatix wrote:
| 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.
| cwillu wrote:
| I've largely lost patience with the current culture of
| sacrificing any backwards compatibility that is slightly
| inconvenient in the name of "improvement".
| jey wrote:
| Anyone have a link to the patch in uutils? Curious to see that
| the problem and solution were.
| janzer wrote:
| 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
| pedrocr wrote:
| This seems to be the Ubuntu bug report:
|
| https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
| cataflam wrote:
| 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
| nine_k wrote:
| 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.
| trollbridge wrote:
| Was there something wrong with the old coreutils that needed
| improvement?
| bn-l wrote:
| It wasn't... "safe"
| throitallaway wrote:
| 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.
| denkmoon wrote:
| 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 wrote:
| 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.
| mort96 wrote:
| 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.
| LtWorf wrote:
| I reported a segfault in "tac" a number of years ago.
| ajross wrote:
| 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.
| agumonkey wrote:
| when your bug it fully typed
| dwroberts wrote:
| Probably stuff like
| https://www.cvedetails.com/cve/CVE-2015-4042/
| username223 wrote:
| 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.
| kstrauser wrote:
| 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.
| bilekas wrote:
| It wasn't rewritten in rust yet. Therefore it wasn't complete.
| /s
| rolandog wrote:
| 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
| LtWorf wrote:
| I've had the same suspicion since I read about it the first
| time.
| ndiddy wrote:
| 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.
| mjmas wrote:
| 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).
| mort96 wrote:
| 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.
| mjmas wrote:
| It looks like we have three major open source imementations:
|
| - GNU coreutils (GPLv3)
|
| - uutils coreutils (MIT)
|
| - busybox (GPLv2)
| CaptainOfCoit wrote:
| 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.
| jcranmer wrote:
| 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
| _zoltan_ wrote:
| no, just the usual... people want to rewrite stuff in Rust
| "just because". it's getting annoying.
| IshKebab wrote:
| 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.
| evil-olive wrote:
| 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.
|
| 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
| none_to_remain wrote:
| There were no buffer overflows, though!
| throitallaway wrote:
| I also can't be hacked if I pull the power to my PC!
| johnny22 wrote:
| It's supposed to pass the coreutils upstream tests. If it does,
| then that would mean the upstream tests still need work
| gpm wrote:
| 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.
| cataflam wrote:
| 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 wrote:
| 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
| e2le wrote:
| 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.
| ls65536 wrote:
| 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).
| jcranmer wrote:
| 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.
| evil-olive wrote:
| 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/14d24f7a530f
| 58...
|
| 1: https://github.com/uutils/coreutils/commit/41d1dfaf440eabb
| a3...
| pixelbeat__ wrote:
| https://github.com/coreutils/coreutils/commit/14d24f7a5
|
| That bring GNU date(1) line coverage from 79.8% to 87.1%
| ok123456 wrote:
| Can we just go back to the real version?
| dmitrygr wrote:
| debian-stable welcomes you
| cmckn wrote:
| My experience tells me that preventing auto-updates may be more
| feature than bug.
| matt3210 wrote:
| > Rewrite in rust so it will have no bugs
|
| You promised!
| IshKebab wrote:
| Nobody promised that. Please don't make things up.
| IlikeKitties wrote:
| The rewrite has NOTHING to do with security and is all about
| licensing. coreutils are GLPv3 rust-coreutils are MIT
| Ginden wrote:
| So what? Standalone binaries don't infect other things with
| copyleft anyway.
| LtWorf wrote:
| Apple never upgraded to GPL3 coreutils, bash and remained
| away from anything GPL3...
| yoyohello13 wrote:
| There is a lot of FUD spread about GPL so companies tend to
| just nope out entirely.
___________________________________________________________________
(page generated 2025-10-23 23:00 UTC)