33 ms·

Date bug in Rust-based coreutils affects Ubuntu 25.10 automatic updates

272 points by blueflow 1y ago

superkuh 1y ago
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 1y ago
  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 1y ago
    I agree, but the post does resonate - Rust still has a very "Ready to make breaking changes on a whim" reputation
    - tempest_ 1y ago
      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 1y ago
        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_ 1y ago
        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.
        skydhash 1y ago
        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.
        uecker 1y ago
        Indeed. This is exactly the problem. It is no fun helping with maintenance of an existing project, fix some boring bug, deal with all the historical constraints, necessary support for old systems, etc. It is so much more fun to cargo-download some stuff and build some new shiny Rust-xyz implementation of Z on your Apple Macbook and even get some HN attention just for this. The problem with all the Rust hype is that people convince themselves that they are actually helping the world by being part of a worthwhile cause to rid the world from old languages, while the main effect is that i draws resources away from much more important efforts and places an even higher burden on the ecosystem - making our main problem - sustainable maintenance of free software - even harder.
        zamadatix 1y ago
        I'm not sure a post about a 12 year long project dealing with fixing bugs to match historical constraints with a make build option was really the best choice for this particular rant.
      - cwillu 1y ago
        I've largely lost patience with the current culture of sacrificing any backwards compatibility that is slightly inconvenient in the name of “improvement”.
      - skydhash 1y ago
        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.
    - awesome_dude 1y ago
      As is the norm for HN and Rust commentary - any slight criticism is met with fury and downvotes.
      - School-Cotton 1y ago
        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" ?
        awesome_dude 1y ago
        All day every day I see "random opinion with nothing to back it up" posts on Hacker News, but are not voted down - discuss.
        baq 1y ago
        Rust users read more xkcd than the average hn poster. Or less. Take your pick.
        rustdebacletime 1y ago
        > What breaking changes has Rust made "on a whim" ? I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. And it caused some projects, like Nix, a lot of pain. https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-type-inference/ https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-...
        aw1621107 1y ago
        > I don't know about "on a whim" Probably not the best way to lead, considering that that phrase is the entire root of the disagreement you're chiming in on! > but this isn't far off in regards to breaking compatibility. I think it might be worth elaborating on why you think that change "isn't far off" being made "on a whim". At least to me, "on a whim" implies something about intent (or more specifically, the lack thereof) that the existence of negative downstream impacts says nothing about. If anything, from what I can tell the evidence suggests precisely the opposite - that the breakage wasn't made "on a whim". The change itself [0] doesn't exactly scream "capricious" to me, and the issue was noticed before Rust 1.80.0 released [1]. The libs team discussed said issue before 1.80.0's release [2] and decided (however (un)wisely one may think) that that breakage was acceptable. That there was at least some consideration of the issue basically disqualifies it from being made "on a whim", in my view. [0]: https://github.com/rust-lang/rust/pull/99969 https://github.com/rust-lang/rust/pull/99969 [1]: https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 [2]: https://github.com/rust-lang/rust/issues/127343#issuecomment-2218261296 https://github.com/rust-lang/rust/issues/127343#issuecomment...
    - School-Cotton 1y ago
      > 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?
      - mort96 1y ago
        I like Rust, but almost all libraries I end up using are on some 0.x version...
        klardotsh 1y ago
        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...
        gldrk 1y ago
        That’s the whole point. Perfectionism and stability are mutually exclusive. What’s ‘worthy of being set in stone’ is very much not set in stone, in an insanely fashion-driven industry like software development.
        baq 1y ago
        Version numbers are bogus anyway. For all you care all those libraries could be YY.MM. Semantic versioning is a lie except for the smallest units.
        mort96 1y ago
        Version numbers are communication. Version 0.x is the clearest way I can imagine to communicate, "do not expect a stable API".
  - ok123456 1y ago
    It's been post-1.0 for a decade, but they keep on changing the definition of "nightly." "Stable" lacks too many quality of life features so most things don't target it.
    - ViewTrick1002 1y ago
      Rust currently has a problem that too few people are using nightly which makes gathering experience and feedback on new features harder. This is a stark difference to back in the early post 1.0 days where many high profile crates needed nightly and everyone was experimenting.
  - rustdebacletime 1y ago
    A little more than a year ago, breakage. https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-type-inference https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-...
    - Avamander 1y ago
      Have you EVER used GCC? I wish each release only had bugs with inferring the type of auto or something.
      - rustdebacletime 1y ago
        And rustc uses LLVM, and has had several bugs as well, whether related to LLVM or just due to itself. But what I linked was intentional breakage, and it caused some people a lot of pain.
        Avamander 1y ago
        Yea, I can think of a lot of intentional GCC breakages as well. Especially ones related to optimizations. If we wrote an article for every one you'd never hear the end of it. So what's actually your point here?
        rustdebacletime 1y ago
        > Especially ones related to optimizations. Did they change the language? GCC is not meant to change the C or C++ languages (unless the user uses some flag to modify the language), there is an ISO standard that they seek to be compliant with. rustc, on the other hand, only somewhat recently got a specification or something from Ferrocene, and that specification looks lackluster and incomplete from when I last skimmed through it. And rustc does not seem to be developed against the official Rust specification.
        Avamander 1y ago
- egorfine 1y ago
  > It is a culture of change and the latest and greatest Good luck achieving anything of long-term value this way.
- k4rli 1y ago
  I wonder how archlinux manages to be so stable and reliable then, being "bleeding edge". Never had a single issue with it.
jey 1y ago
Anyone have a link to the patch in uutils? Curious to see that the problem and solution were.
- janzer 1y ago
  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/0047c7e66ffb579713d0673dec17875d7e6fbfeb https://github.com/uutils/coreutils/commit/0047c7e66ffb57971... 1: https://news.ycombinator.com/item?id=45687743 https://news.ycombinator.com/item?id=45687743
- pedrocr 1y ago
  This seems to be the Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
- cataflam 1y ago
  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/ https://lwn.net/Articles/1043123/ 1: https://github.com/uutils/coreutils/issues/8621 https://github.com/uutils/coreutils/issues/8621 2: https://github.com/uutils/coreutils/pull/8630 https://github.com/uutils/coreutils/pull/8630
  - nine_k 1y ago
    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.
    - 1y ago
trollbridge 1y ago
Was there something wrong with the old coreutils that needed improvement?
- arresin 1y ago
  It wasn’t… “safe”
  - throitallaway 1y ago
    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 1y ago
      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 1y ago
      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.
      - johnisgood 1y ago
evil-olive 1y ago
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/+changelog https://launchpad.net/ubuntu/questing/+source/rust-coreutils... 1: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu... 2: https://github.com/uutils/coreutils/issues/8621 https://github.com/uutils/coreutils/issues/8621 3: https://github.com/uutils/coreutils/pull/8630 https://github.com/uutils/coreutils/pull/8630
- johnny22 1y ago
  It's supposed to pass the coreutils upstream tests. If it does, then that would mean the upstream tests still need work
  - gpm 1y ago
    It... doesn't though: https://uutils.github.io/coreutils/docs/test_coverage.html 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.
ok123456 1y ago
Can we just go back to the real version?
- dmitrygr 1y ago
  debian-stable welcomes you
  - brokenmachine 1y ago
    I think this is where I'll be 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 that fail their own tests is madness.
    - ok123456 1y ago
      I've been using Debian stable exclusively for the past three years on servers since Canonical doubled-down on "snaps" despite all of their customers telling them on no uncertain terms that "snaps" are horrible. Also Canonical was named and shamed by people trying to get jobs as the poster child of everything wrong with tech recruiting in [current year].
      - brokenmachine 1y ago
        Yes I discovered snaps in 24.04 when I tried to install Firefox. Eventually installed from the PPA but it was an unexpected PITA.
      - LtWorf 1y ago
        Uh what's wrong with canonical recruitment? They had me do an automated IQ test, specified I had to do it in my native language, and it turned out it had been machine translated with some tools that was decades old, so I didn't understand anything at all. I am sure they've also blacklisted me because I get autorejected since then. I'm also a Debian Developer so I don't have any relevant experience that could be useful in working at Canonical. Where do you see anything wrong with their process?
deleted 1y ago
[deleted]
wartywhoa23 1y ago
[flagged]
matt3210 1y ago
[flagged]
- IshKebab 1y ago
  Nobody promised that. Please don't make things up.
  - johnisgood 1y ago
    It would be silly to do so, for sure.
IlikeKitties 1y ago
The rewrite has NOTHING to do with security and is all about licensing. coreutils are GLPv3 rust-coreutils are MIT
- Ginden 1y ago
  So what? Standalone binaries don't infect other things with copyleft anyway.
  - LtWorf 1y ago
    Apple never upgraded to GPL3 coreutils, bash and remained away from anything GPL3…
    - Ginden 1y ago
      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 1y ago
    There is a lot of FUD spread about GPL so companies tend to just nope out entirely.
  - mort96 1y ago
    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 1y ago
      This hasn't stopped anybody from releasing a product that I'm aware of.
_zagj 1y ago
> 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-6196-rewriting-the-future-of-the-linux-essential-packages-in-rust-/ 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/#q104831479 https://desuarchive.org/g/thread/104831348/#104831809 https://desuarchive.org/g/thread/104831348/#104831809
- elcritch 1y ago
  > 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.
  - uecker 1y ago
    Of course! But the problem is much more severe. I can't comment on coreutils, but there are not enough resources for high quality maintenance of the core tool chain. It is completely surprising that effort is wasted for creating new implementations when we do not even have enough resources to properly maintain the existing ones. It is based on the - completely wrong - idea that all the problems we have is from using the wrong language and will magically go away with Rust instead of a fundamental maintenance problem of free software. So we now makes things substantially worse based on this incorrect analysis.
1vuio0pswjnm7 1y ago
https://lists.ubuntu.com/archives/ubuntu-security-announce/2025-October/009890.html https://lists.ubuntu.com/archives/ubuntu-security-announce/2... A classic
aero-glide2 1y ago
Im okay with this. This is how we find out issues. As long as these are sorted before the LTS release, no problem.
- rustdebacletime 1y ago
  [flagged]
- StopDisinfo910 1y ago
  You are ok about the core utils being replaced by a rewrite for no obvious reason and said rewrite being so broken that an allegedly stable distribution actually can’t properly update? I mean, all good then.
  - atoav 1y ago
    My expectation would be that every bug in a Rust replacement is going to receive the brightest spotlight that can be found. If the rest of coreutils is bug free cast the first stone. I do not think reimplementing stuff in Rust is a bad thing. Why? Because reimplementing stuff is a very good way to througly check the original. It is always good to have as many eyeballs om the code as possible.
    - StopDisinfo910 1y ago
      Replacing battle tested software with untested rewrite is always a bad idea even if the rewrite is written a trendy language, key word being untested. I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler.
      - orangeboats 1y ago
        > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right. It is true that the borrow checker doesn't prevent ALL bugs though. Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.
sudahtigabulan 1y ago
The top comment is hilarious: > The next Ubuntu release will be called Grateful Guinea-Pig
- deleted 1y ago
  [deleted]
deleted 1y ago
[deleted]
igravious 1y ago
25.10 is unusable. I've never said that about a non-LTS Ubuntu release.
- letmetweakit 1y ago
  Can you elaborate?
theptip 1y ago
So, what’s the state of the art in guided state-space exploration/fuzzing? Seems if you have a reference implementation your fuzzer should be able to do some nice white-box validation to ensure you are behaving the same as the old implementation.
- maxbond 1y ago
  For this type of thing I think property testing would work well. It would take a fair about of work to write a proptest for the entire input space of the tool. But it's achievable and as durable as the CLI arguments (so for this specific case, very unlikely to change in a backwards incompatible way). And this kind of rote work with good reference materials (namely the man pages) is amenable to being generated. Whatever language you're working in there is probably a port of Hypothesis or quickcheck. For Rust I use the `proptest` crate, but for differential testing of a CLI I would probably use the Python Hypothesis package and invoke the commands externally.

272 points by blueflow 1y ago

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 1y ago
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 1y ago
  I agree, but the post does resonate - Rust still has a very "Ready to make breaking changes on a whim" reputation
  - tempest_ 1y ago
    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 1y ago
      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_ 1y ago
        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.
        skydhash 1y ago
        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.
        uecker 1y ago
        Indeed. This is exactly the problem. It is no fun helping with maintenance of an existing project, fix some boring bug, deal with all the historical constraints, necessary support for old systems, etc. It is so much more fun to cargo-download some stuff and build some new shiny Rust-xyz implementation of Z on your Apple Macbook and even get some HN attention just for this. The problem with all the Rust hype is that people convince themselves that they are actually helping the world by being part of a worthwhile cause to rid the world from old languages, while the main effect is that i draws resources away from much more important efforts and places an even higher burden on the ecosystem - making our main problem - sustainable maintenance of free software - even harder.
        zamadatix 1y ago
        I'm not sure a post about a 12 year long project dealing with fixing bugs to match historical constraints with a make build option was really the best choice for this particular rant.
    - cwillu 1y ago
      I've largely lost patience with the current culture of sacrificing any backwards compatibility that is slightly inconvenient in the name of “improvement”.
    - skydhash 1y ago
      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.
  - awesome_dude 1y ago
    As is the norm for HN and Rust commentary - any slight criticism is met with fury and downvotes.
    - School-Cotton 1y ago
      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" ?
      - awesome_dude 1y ago
        All day every day I see "random opinion with nothing to back it up" posts on Hacker News, but are not voted down - discuss.
        baq 1y ago
        Rust users read more xkcd than the average hn poster. Or less. Take your pick.
      - rustdebacletime 1y ago
        > What breaking changes has Rust made "on a whim" ? I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. And it caused some projects, like Nix, a lot of pain. https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-type-inference/ https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-...
        aw1621107 1y ago
        > I don't know about "on a whim" Probably not the best way to lead, considering that that phrase is the entire root of the disagreement you're chiming in on! > but this isn't far off in regards to breaking compatibility. I think it might be worth elaborating on why you think that change "isn't far off" being made "on a whim". At least to me, "on a whim" implies something about intent (or more specifically, the lack thereof) that the existence of negative downstream impacts says nothing about. If anything, from what I can tell the evidence suggests precisely the opposite - that the breakage wasn't made "on a whim". The change itself [0] doesn't exactly scream "capricious" to me, and the issue was noticed before Rust 1.80.0 released [1]. The libs team discussed said issue before 1.80.0's release [2] and decided (however (un)wisely one may think) that that breakage was acceptable. That there was at least some consideration of the issue basically disqualifies it from being made "on a whim", in my view. [0]: https://github.com/rust-lang/rust/pull/99969 https://github.com/rust-lang/rust/pull/99969 [1]: https://github.com/rust-lang/rust/issues/127343 https://github.com/rust-lang/rust/issues/127343 [2]: https://github.com/rust-lang/rust/issues/127343#issuecomment-2218261296 https://github.com/rust-lang/rust/issues/127343#issuecomment...
  - School-Cotton 1y ago
    > 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?
    - mort96 1y ago
      I like Rust, but almost all libraries I end up using are on some 0.x version...
      - klardotsh 1y ago
        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...
        gldrk 1y ago
        That’s the whole point. Perfectionism and stability are mutually exclusive. What’s ‘worthy of being set in stone’ is very much not set in stone, in an insanely fashion-driven industry like software development.
      - baq 1y ago
        Version numbers are bogus anyway. For all you care all those libraries could be YY.MM. Semantic versioning is a lie except for the smallest units.
        mort96 1y ago
        Version numbers are communication. Version 0.x is the clearest way I can imagine to communicate, "do not expect a stable API".
- ok123456 1y ago
  It's been post-1.0 for a decade, but they keep on changing the definition of "nightly." "Stable" lacks too many quality of life features so most things don't target it.
  - ViewTrick1002 1y ago
    Rust currently has a problem that too few people are using nightly which makes gathering experience and feedback on new features harder. This is a stark difference to back in the early post 1.0 days where many high profile crates needed nightly and everyone was experimenting.
- rustdebacletime 1y ago
  A little more than a year ago, breakage. https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-type-inference https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-...
  - Avamander 1y ago
    Have you EVER used GCC? I wish each release only had bugs with inferring the type of auto or something.
    - rustdebacletime 1y ago
      And rustc uses LLVM, and has had several bugs as well, whether related to LLVM or just due to itself. But what I linked was intentional breakage, and it caused some people a lot of pain.
      - Avamander 1y ago
        Yea, I can think of a lot of intentional GCC breakages as well. Especially ones related to optimizations. If we wrote an article for every one you'd never hear the end of it. So what's actually your point here?
        rustdebacletime 1y ago
        > Especially ones related to optimizations. Did they change the language? GCC is not meant to change the C or C++ languages (unless the user uses some flag to modify the language), there is an ISO standard that they seek to be compliant with. rustc, on the other hand, only somewhat recently got a specification or something from Ferrocene, and that specification looks lackluster and incomplete from when I last skimmed through it. And rustc does not seem to be developed against the official Rust specification.
        Avamander 1y ago
egorfine 1y ago
> It is a culture of change and the latest and greatest Good luck achieving anything of long-term value this way.
k4rli 1y ago
I wonder how archlinux manages to be so stable and reliable then, being "bleeding edge". Never had a single issue with it.

jey 1y ago

Anyone have a link to the patch in uutils? Curious to see that the problem and solution were.

janzer 1y ago
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/0047c7e66ffb579713d0673dec17875d7e6fbfeb https://github.com/uutils/coreutils/commit/0047c7e66ffb57971... 1: https://news.ycombinator.com/item?id=45687743 https://news.ycombinator.com/item?id=45687743
pedrocr 1y ago
This seems to be the Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
cataflam 1y ago
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/ https://lwn.net/Articles/1043123/ 1: https://github.com/uutils/coreutils/issues/8621 https://github.com/uutils/coreutils/issues/8621 2: https://github.com/uutils/coreutils/pull/8630 https://github.com/uutils/coreutils/pull/8630
- nine_k 1y ago
  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.
  - 1y ago

trollbridge 1y ago

Was there something wrong with the old coreutils that needed improvement?

arresin 1y ago
It wasn’t… “safe”
- throitallaway 1y ago
  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 1y ago
    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 1y ago
    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.
    - johnisgood 1y ago

evil-olive 1y ago

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/+changelog https://launchpad.net/ubuntu/questing/+source/rust-coreutils... 1: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu... 2: https://github.com/uutils/coreutils/issues/8621 https://github.com/uutils/coreutils/issues/8621 3: https://github.com/uutils/coreutils/pull/8630 https://github.com/uutils/coreutils/pull/8630

johnny22 1y ago
It's supposed to pass the coreutils upstream tests. If it does, then that would mean the upstream tests still need work
- gpm 1y ago
  It... doesn't though: https://uutils.github.io/coreutils/docs/test_coverage.html 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.

ok123456 1y ago

Can we just go back to the real version?

dmitrygr 1y ago
debian-stable welcomes you
- brokenmachine 1y ago
  I think this is where I'll be 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 that fail their own tests is madness.
  - ok123456 1y ago
    I've been using Debian stable exclusively for the past three years on servers since Canonical doubled-down on "snaps" despite all of their customers telling them on no uncertain terms that "snaps" are horrible. Also Canonical was named and shamed by people trying to get jobs as the poster child of everything wrong with tech recruiting in [current year].
    - brokenmachine 1y ago
      Yes I discovered snaps in 24.04 when I tried to install Firefox. Eventually installed from the PPA but it was an unexpected PITA.
    - LtWorf 1y ago
      Uh what's wrong with canonical recruitment? They had me do an automated IQ test, specified I had to do it in my native language, and it turned out it had been machine translated with some tools that was decades old, so I didn't understand anything at all. I am sure they've also blacklisted me because I get autorejected since then. I'm also a Debian Developer so I don't have any relevant experience that could be useful in working at Canonical. Where do you see anything wrong with their process?

deleted 1y ago

[deleted]

wartywhoa23 1y ago

[flagged]

matt3210 1y ago

[flagged]

IshKebab 1y ago
Nobody promised that. Please don't make things up.
- johnisgood 1y ago
  It would be silly to do so, for sure.

IlikeKitties 1y ago

The rewrite has NOTHING to do with security and is all about licensing. coreutils are GLPv3 rust-coreutils are MIT

Ginden 1y ago
So what? Standalone binaries don't infect other things with copyleft anyway.
- LtWorf 1y ago
  Apple never upgraded to GPL3 coreutils, bash and remained away from anything GPL3…
  - Ginden 1y ago
    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 1y ago
  There is a lot of FUD spread about GPL so companies tend to just nope out entirely.
- mort96 1y ago
  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 1y ago
    This hasn't stopped anybody from releasing a product that I'm aware of.

_zagj 1y ago

> 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-6196-rewriting-the-future-of-the-linux-essential-packages-in-rust-/ 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/#q104831479 https://desuarchive.org/g/thread/104831348/#104831809 https://desuarchive.org/g/thread/104831348/#104831809

elcritch 1y ago
> 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.
- uecker 1y ago
  Of course! But the problem is much more severe. I can't comment on coreutils, but there are not enough resources for high quality maintenance of the core tool chain. It is completely surprising that effort is wasted for creating new implementations when we do not even have enough resources to properly maintain the existing ones. It is based on the - completely wrong - idea that all the problems we have is from using the wrong language and will magically go away with Rust instead of a fundamental maintenance problem of free software. So we now makes things substantially worse based on this incorrect analysis.

1vuio0pswjnm7 1y ago

https://lists.ubuntu.com/archives/ubuntu-security-announce/2025-October/009890.html https://lists.ubuntu.com/archives/ubuntu-security-announce/2... A classic

aero-glide2 1y ago

Im okay with this. This is how we find out issues. As long as these are sorted before the LTS release, no problem.

rustdebacletime 1y ago
[flagged]
StopDisinfo910 1y ago
You are ok about the core utils being replaced by a rewrite for no obvious reason and said rewrite being so broken that an allegedly stable distribution actually can’t properly update? I mean, all good then.
- atoav 1y ago
  My expectation would be that every bug in a Rust replacement is going to receive the brightest spotlight that can be found. If the rest of coreutils is bug free cast the first stone. I do not think reimplementing stuff in Rust is a bad thing. Why? Because reimplementing stuff is a very good way to througly check the original. It is always good to have as many eyeballs om the code as possible.
  - StopDisinfo910 1y ago
    Replacing battle tested software with untested rewrite is always a bad idea even if the rewrite is written a trendy language, key word being untested. I’m still shocked by the number of people who seem to believe that the borrow checker is some kind of magic. I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler.
    - orangeboats 1y ago
      > I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler. Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right. It is true that the borrow checker doesn't prevent ALL bugs though. Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.

sudahtigabulan 1y ago

The top comment is hilarious: > The next Ubuntu release will be called Grateful Guinea-Pig

deleted 1y ago
[deleted]

deleted 1y ago

[deleted]

igravious 1y ago

25.10 is unusable. I've never said that about a non-LTS Ubuntu release.

letmetweakit 1y ago
Can you elaborate?

theptip 1y ago

So, what’s the state of the art in guided state-space exploration/fuzzing? Seems if you have a reference implementation your fuzzer should be able to do some nice white-box validation to ensure you are behaving the same as the old implementation.

maxbond 1y ago
For this type of thing I think property testing would work well. It would take a fair about of work to write a proptest for the entire input space of the tool. But it's achievable and as durable as the CLI arguments (so for this specific case, very unlikely to change in a backwards incompatible way). And this kind of rote work with good reference materials (namely the man pages) is amenable to being generated. Whatever language you're working in there is probably a port of Hypothesis or quickcheck. For Rust I use the `proptest` crate, but for differential testing of a CLI I would probably use the Python Hypothesis package and invoke the commands externally.