Bug in Rust-Based Uutils Broke Ubuntu 25.10 Automatic Update Checks (omgubuntu.co.uk) 50
"Ubuntu's decision to switch to Rust-based coreutils in 25.10 hasn't been the smoothest ride," writes the blog OMG Ubuntu, "as the latest — albeit now resolved — bug underscores."
[Coreutils] are used by a number of processes, apps and scripts, including Ubuntu's own unattended-upgrades process, which automatically checks for new software updates. Alas, the Rust-based version of date had a bug which meant Ubuntu 25.10 desktops, servers, cloud and container images were not able to automatically check for updates when configured. Unattended-upgrades hooks into the date utility to check the timestamp of a reference file of when an update check was last run and, past a certain date, checks again. But date was incorrectly showing the current date, always.
A fix has been issued so only Ubuntu 25.10 installs withrust-coreutils 0.2.2-0ubuntu2 (or earlier) are affected.
A fix has been issued so only Ubuntu 25.10 installs withrust-coreutils 0.2.2-0ubuntu2 (or earlier) are affected.
specification & testing (Score:5, Insightful)
Seems to me from reading the article this -should have been caught- by testing against the specification.
"date -r reports current date instead of date specified by reference file." This should have ben tested, it's not a particularly complex test case.
Re: (Score:3)
Your (apparently ignored) FP reminded me of my own bad experience with 25.10. I think the bad experience was basically due to a lack of regression testing leading to more bad experiences with LLMs trying to help me fix the problem.
The problem I found was lost OSes. Turned out that the new 25.10 default is to disable the os-prober function in GRUB. I started with no idea of where the other partitions had gone, but eventually, with lots of so-called "help" from a couple of so-called "AI" helpers, now I believ
Re: specification & testing (Score:2)
I've been doing software engineering for over 20 years now ans, just like unicorns, I'm yet to see a specification document which does more than scratch the surface.
Re: (Score:2)
I've been doing software engineering for over 20 years now ans, just like unicorns, I'm yet to see a specification document which does more than scratch the surface.
Then clearly you've not worked in a safety-critical regime, where specifications are required to fully cover behavior sufficient to generate test cases that cover 100% of the requirements, and by extension 100% of the code branches.
But even in "regular" development, the API specifications I wrote, implemented and tested were all expected to be sufficient to be useful for test and verification.
Frankly, if you haven't seen this level of specification, I really question if you've been doing "software engineeri
Re:specification & testing (Score:4)
Re: (Score:2)
That's amazing, frankly.
I wrote a simple bash script the other day to handle a video encoding queue, with this line:
It's running on Debian 12 but to imagine that if it were running on Ubuntu it would have failed?
Wild that this wasn't caught as soon as the dud utility shipped in a distro. I would have expected somebody's scripts to have failed, they ran it under bash -x and thought, "Oh, boy," then off to file a bug.
I like the idea of using
Re: (Score:2)
You can do software engineering in any language, even C or Visual Basic. But it's easier with languages that provide more precision in specification and in behavior. Once you get used to it, strong typing, particularly for scalars (integer types) is your friend. It can catch at compile-time subtle bugs that can be hard to find. Similarly, languages that make it easy to define chunks of code with well defined interfaces/APIs (and that do information hiding on details) is a huge advantage in large (as in
TL;DR (Score:5, Funny)
Rust nerds can't get a date. :-)
Re:TL;DR (Score:4, Funny)
Well, technically speaking - they can only get ONE date.
Re:TL;DR (Score:5, Funny)
Well, technically speaking - they can only get ONE date.
according to the summary they apparently had a different date every day.
players!
Re: (Score:2)
Technically, they can't get an old date.
And IRL ya might not want to. You should always update. Upgrades are desirable but optional.
Re: TL;DR (Score:2)
Why did the Rust developer failed at dating?
He wanted to find someone with no undefined behavior and a lifetime guarantee.
Re: (Score:2)
Being memory safe is an advantage, because, some things are better left forgotten, some things are better left where they lay.
Things I don't like in life or in code (Score:4, Insightful)
1. Fixing shit that ain't broke
2. Renaming stuff because reasons
3. Reinventing the hammer
4. Assuming every problem is a nail
Re:Things I don't like in life or in code (Score:4, Interesting)
5. Assuming every problem has a unique cause as opposed to a symphony of causes.
6. Assume every problem is singular and not a combination of other problems where one problem can obscure another.
Re:Things I don't like in life or in code (Score:4)
Re: (Score:2)
All you need is an OS written in assembler.
Say it Ain't So! (Score:3, Insightful)
Re: (Score:3)
Except fad languages don't usually have much community support behind it. Lots of things are being reimplemented in rust to eliminate memory safety bugs. Lots of tools are mature, but likely may have hidden bugs that might be exploited for some untowards purpose.
And it's in the kernel, where some developers have found benefits to not having to worry about tricky memory handling issues especially in complex devices like GPUs where the memory buffer can be allocated by a thread long since gone and forgotten a
Re: (Score:2)
There used to be a time when Java had support everywhere. It seemed unstoppable, there was so much community support.
Then it faded (etymology: early 14c., "lose brightness, grow pale," from Old French fader "become weak, wilt, wither," from fade (adj.) "pale, weak; insipid, tasteless" (12c.), probably from Vulgar Latin *fatidus, which is said to be a blending of Latin fatuus "silly, tasteless" and vapidus "flat, flavorless." [etymonline.com])
Re: (Score:2)
This bug has nothing at all to do with the language used, they just screwed up the code. This mistake could happen in any language.
Re: (Score:2)
Re: Rust...so what? (Score:4, Insightful)
Maybe.
Maybe there's also a subtler but much more important point about engineering philosophy to be made here:
The new shiny language with cool stuff that's better/faster/safer than the legacy language does not automatically solve all the problems that the artifact implemented in the legacy language has had to contend with and resolve over a long time; you still have to do it again in the new language.
Whether it is worth doing so is a balance between realizing the benefits of the new tools for further development and the cost in time of retreading the old ground.
To rewrite merely for the sake of rewriting utilities that are relatively stable and don't change much (meaning not much future benefit to be gained) is to accept the cost of the rewrite solely for the cosmetic benefits of jumping on the new language bandwagon. And the fact that the new tools aren't quite within spec means that the rewrite wasn't done well.
If something is done poorly and for largely cosmetic reasons, it is usually looked down on both by geeks and bean counters as a waste.
Re: (Score:2)
Ancillary to that, sometimes an implementation can obscure just what problems to which it is or has become (due to changes) immune. And sometimes it is not even clear that the old code made some problem invisible since the problem never appeared in testing.
because (Score:5, Insightful)
The entire reason this replacement happened was because some jackass wanted to rewrite decades-old code in rust. It wasn't as if he had developed a better version of the utilities and it just happened to be written in rust. No, the replacements were buggy as hell (couldn't even work with the OS's own needed functionality let alone what third party software expected) and many times slower.
The rust fanatics are utterly insufferable -- in the Linux kernel it was said that rust was being allowed so that people could write subsystems in rust. Okay, fair enough, if someone wants to write a GPU driver in rust because the memory management makes it easier, by all means go for it. Might be a pain in the ass because the code needs to comply with existing APIs which were designed around C conventions, but that's a choice people can make. Instead these maniacs are going through the rest of the kernel trying to port things like the scheduler to rust simply for the sake of doing so.
I note that fucking git is going to require rust starting in version 3. Even though major platforms for which git exists today do not have a rust compiler. These maniacs just do not give a fuck about anything except their own narcissism.
Re: (Score:2)
Re: (Score:2)
Anything not Tier 1 shouldn't qualify as "supported"
https://doc.rust-lang.org/nigh... [rust-lang.org]
Take your pick. I'd say armv7 is still a big player in the world.
Re: because (Score:2)
And there are Intel Macs still out in the world that are still supported by Apple.
Re: (Score:1)
That's fair. It is definitely the sort of thing you have to think about when you choose to rewrite a mature system, in whatever language.
But yeah, the fact this rewrite happened in rust appears to be irrelevant to this story... just like it was irrelevant to the CloudFlare "rewrite in rust leads to big speed-up" story yesterday.
Re: Rust...so what? (Score:3)
What's relevant is that this would not have ever been attempted in another language. Rust zealots have a special form of brain damage that causes them to try to treat Rust as a computer worm, infecting everything it touches. Without the Rust mental disease, this issue would not have happened.
Re: (Score:2)
Yeah, you could say that. On the other hand you could say the rewrite was an investment in maintainability--sacrificing immediate stability for a future of lack of memory issues and reduced possibility of control flow mistakes or type errors.
Re: Rust...so what? (Score:4, Insightful)
The problem is the target of this rewrite.
These are shell utilities. These are very mature shell utilities. They types of problems Rust fixes are not for the most relevant.
Might there be memory related bugs present, sure but if leaks, use after free(s), etc exit they are so small and so hard to hit they effectively don't matter at this point because the severe enough to matter ones were fixed a decade ago, and these are not long lived processes.
Security wise these are running as the owner, they don't generally represent an escalation or even lateral path. When they do the do so because some other owner process shell's out to them so attacks must be 'second order' or higher. Those are both incredibly difficult to find, and generally pretty difficult to exploit even when you know of them. For a threat to be real you need 1) and serious data-to-control violation to exist in the utility, IE grep'ing or sorting a crafted file triggers part of the file to be executed or something like that. Which would have to involve a pretty obscure set of flags/usecase ortherwise again it would already have been fixed, the affected application needs to use the utility in the obscure way, and it needs to be possible to craft a payload that passes any other lays of validation and still meets the exploit conditions...
I don't want to be all anti-rust here, because there is value in memory safety. Now I would argue that memory-safe C++ is going to be more familiar to everyone and would be a better all around choice as a systems language; especially because the impedance with existing C interfaces is better. Rust is fine on its own but I don't think actually belongs in Unix-like platform... Rewriting more complex things like Curl, parts of the Kernel, Sudo, etc in something memory safe probably has security dividends and maybe performance dividends. Rewriting "sort" does not.
Let's be honest about why the Rust crew took on this project. They are acting like a cancer trying to get as much core stuff into Rust as possible to help force everyone to deal with it. Like a cancer they attacked what they saw as an easy target, even though it isn't a valuable, one. Its kinda like systemd taking over things like DNS resolution that it absolutely does not need to do but simple can. Its bad practice all around, and will make my general views of supporting rust anyway far more prejudicial against.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Rust (Score:2)
Re: (Score:2)
Quite. Indeed the system hardware, and other processes running can be problematic then interfere with the gee-whiz golly safe memory Rust app or library.
JoshK.
Safe C compiler (Score:3)
Re: Safe C compiler (Score:3)
FIL looks nice, but it is garbage collected with run time validation. Rust is deterministically memory managed with zero cost abstraction.
Re: Safe C compiler (Score:2)
Re: Safe C compiler (Score:2)
Yes, that is possibly true in this case. I suspect though this rewrite is for three reasons: memory safety, to see if it can be done for more widespread usage, and to switch licence. FIL might achieve one of these two.
Re: Safe C compiler (Score:2)
Re: (Score:2)
FIL has the old compromise of getting memory safety at the cost of a Garbage Collector. This is nothing new, and certainly not something that would compete with Rust.
Professor Frink.... (Score:2)
Professor Frink from the Simpsons said it best (the timing for...about chaos theory and robots rising up to annihilate the humans...)
"Whoops! Forgot the carry..." (as the robots start to annihilate humans.) https://www.youtube.com/watch?... [youtube.com]
Right now its Rust, the greatest thing since sliced bread, before that .NET/CLR with managed code, before that Java, and then COM, and then C++
The "xkcd" cycle: https://www.xkcd.com/2044/ [xkcd.com]
JoshK.
The Rusties Will Keep Pushing (Score:3)
Core rule of software engineering (Score:5, Insightful)
Never rewrite an old, mature, reliable piece of software that works. The complex, spaghetti code is there for a reason. Someone had gone through all the complex use cases throughout years of development at the personal cost of ample grey hair, and still made it work. Its a fragile yet complex and beautiful thing. Don't fix it if it ain't broken.
Re: (Score:2)
IMNSHO, that's solid advice to give a programmer - never take on such a project cause of all those reasons. However, I don't think that rule applies to software engineering or systems design, and coreutils is an excellent example of this situation. Those utils, like "cp", "mv", and "rm", have numerous independent implementations already (FWIW, I'm grouping in similar utilities from the other *nix's). The well established usage and small codebase make them prime candidates for rewrites. But if your boss come