Rust in the FreeBSD kernel

Hah. Many commandline commands (coreutils in Linux speak) re-written in Rust for security, now causing a security issue:

Ubuntu 25.10 Unattended Upgrades Broken Due To Rust Coreutils Bug - Phoronix

www.phoronix.com www.phoronix.com

"
Besides the early fallout of switching to Rust Coreutils on Ubuntu 25.10 causing some breakage, a more pressing issue has been discovered: Ubuntu 25.10's unattended upgrades functionality for automatic security updates is currently broken due to a Rust Coreutils bug.

Earlier this month it was reported that the date -r command can report the wrong date on Ubuntu 25.10 due to a Rust Coreutils difference compared to GNU Coreutils. It was noted that this could cause issues for backup scripts and other software relying on the "date -r" output and behavior being the same as GNU Coreutils.
"

So much for re-writing existing code.
 
cracauer@ said:
So much for re-writing existing code.
Click to expand...
As one Intel chip designer put it : "implement the old ISA bit for bit and bug for bug". They did a visit to MS to remind them not to depend upon undocumented side effects, only to witness a meeting between the future developments department and the legacy support right before "knifes were drawn".
 
cracauer@ said:
Earlier this month it was reported that the date -r command can report the wrong date on Ubuntu 25.10 due to a Rust Coreutils difference compared to GNU Coreutils. It was noted that this could cause issues for backup scripts and other software relying on the "date -r" output and behavior being the same as GNU Coreutils.
Click to expand...
This simply means that not all of security issues are of "memory safety".
Even though the number of issues are fewer than memory safety issues, the severities can be higher.
 
cracauer@ said:
It is an interesting question whether you should kick out libraries that are unmaintained and known vulnerable.

Doing the kickout would make all projects using the library (even as an indirect dependency) fail to compile.
Click to expand...
It's almost like there's no easy way out of dependency hell (or DLL hell if you're a Windows type.) But hey, keep writing more and more package managers that allow you to download the Internet and damn the consequences.

A sad irony that seems to be overlooked is that the original author of Rust's "Cargo" knew the dangers of just adding dependencies until things start working and then walking away. See Cargo Cult Programming.
 
cracauer@ said:
It is an interesting question whether you should kick out libraries that are unmaintained and known vulnerable.

Doing the kickout would make all projects using the library (even as an indirect dependency) fail to compile.
Click to expand...
I was concerned about keepassxc and botan2 for a bit (post-install message), but iirc it was updated to use botan3 and is fine now!
 
cracauer@ said:
Apparently some people ran the GNU coreutils test suite against the Rust coreutils, which showed many failures and the Ubuntus went ahead anyway.
Click to expand...
At least GNU actually has a regression test suite, who knows what the rust coreutils rewrite team have. Ubuntu lost their way years ago...

If they can't get a few standalone command-line programs to work, what chance have they got in the kernel?
 
Actually it will be "C rest in peace" once they've re-written everything in rust and made C obsolete. I'm sure that's the plan. They are determined not to pay, for software development.
C is too hard; the people they want to hire - untrained fresh graduates, H1B's and low cost offshore programmers, can't write good quality code in it. Most of them, anyway.

It remains to be seen whether rust, along with AI code generation, is the fix they hope it is. This is how they are going to de-skill programming and replace most of what we currently think of as programmers with low-cost cut and paste "vibe coders", mostly offshore, who don't understand the code they are working on. Hence the need for a "safe" language; AI and the language itself will prevent the worst security blunders from being placed into the code. The process will occur over perhaps 5-10 years, during which most of the legacy C and C++ code will be squeezed out of the system, and what's left of the existing skilled workforce can be laid off.
 
Jose said:
A dark vision, but unfortunately it has a lot of truth in it. I plan to be retired and maybe fighting fires for a fee when things explode and the vibe coders are useless.
Click to expand...
Well, let's hope it doesn't turn out quite as bad as that. But it won't surprise me all that much if it does. If you look at where investment is going... billions into AI, and billions more into offshore software development. There was a time when assembly programmers were king. Now, there are hardly any of us left. Perhaps C will survive in embedded. Perhaps.

People might object and say "but Rust is also difficult to learn". But perhaps they won't need to learn it, if the AI is going to write the code for them. Time will tell, I guess.
 
There seem to be FUDs (i.e., by US gov.) that all projects SHALL switch to memory-safe languages.
If so, hardwares should become memory-safety-aware first.
Without it, low level codes that memory-safe languages cannot describe are still memory-unsafe. The "minimal" (I won't say "sufficient") requirements would be that currently implemented on mainframes, even for IoTs.
Nonsense! Would be too costly.

And the FUDs seem to overly stating that memory-safe languages make softwares completely safe, which is not at all true.
 
tingo said:
even if Rust is better for memory safety, it won't protect you against every stupid thing a developer can do. The bug in question wasn't related to memory safety.
Click to expand...

Yes. It still illustrates that re-implementing something that has a solid, much-revisited codebase can be less secure than the old code.
 
I also don't like the tone of that email. How is a random architecture's maintainer supposed to come up with a Rust toolchain in 6 months? This is not the right way to decide the set of architectures. If this was about a new subsystem that is written in Rust it would look a little better. But the code exists and has for a long time.
 
This isn't beng driven by developers. It's coming from whoever is holding the purse strings. Someone has swallowed the line that if they (re)write everything in rust there won't be more hacking attacks, and they can tell salt typhoon and fancy bear to go jump. I will believe it when I see it.
 
blackbird9 said:
This isn't beng driven by developers. It's coming from whoever is holding the purse strings.
Click to expand...
Indeed. Just like they did with the "White House", the Rust lobbying committee are quite smart; they target the right people to confuse. Usually these are non-technical people who hold sway but have limited technical understanding.

When it comes to the work though, it falls apart because it is not actionable and things reset back, so its not really a worry, otherwise Java/.NET, Ada, etc would have replaced everything years ago.
 
cracauer@ said:
I also don't like the tone of that email. How is a random architecture's maintainer supposed to come up with a Rust toolchain in 6 months? This is not the right way to decide the set of architectures. If this was about a new subsystem that is written in Rust it would look a little better. But the code exists and has for a long time.
Click to expand...
Hopefully Debian dropping those arches means more visibility to NetBSD.
 
You must log in or register to reply here.
Back
Top