Rust-Based Coreutils 0.0.26 Increases Compatibility With GNU Coreutils

[aerospace]

I have interpolated that line, without adding a saturation curve.
Then it will not be finished this year. But next year it will be.

My MS Paint statistical regression skills tell me that it will be fully compatible by January 2026 + 2 months for bugs and Christmas +- 1 month

[geearf]

I haven't tested uutils, but ripgrep is much faster than good old grep.

https://github.com/scullionw/dirstat-rs is also much much faster than dir here.
Look wise it was not my favorite, but the speed gained me.

[CommunityMember]

One day uutils will be compatible with gnu coreutils more than gnu coreutils itself.

I wonder if Apple will choose to update macOS with uutils (as the license of uutils is compatible with macOS).

[QwertyChouskie]

Memory safety is nice, but I'm somehow concerned that to build this it has almost 300 dependencies. I'm not sure that is a win for security.

https://github.com/uutils/coreutils/blob/0.0.26/Cargo.lock

Holy modularity, Batman! You weren't kidding!

On one hand, having more small modules as opposed to fewer big ones means that any given module is likely more easily auditable, but on the other hand, the sheer number of modules makes the likelihood of an XZ Utils incident too high for my liking. Given how, well, core the coreutils are, if this gets widespread adoption, every module in that list is an XZ begging for a malicious actor to try to take over.

[EphemeralEft]

I have interpolated that line, without adding a saturation curve.
Then it will not be finished this year. But next year it will be.

Nice graph, although I think there are some typos in your x-axis.

My guess is that the lines will become asymptotic near the end.

[Developer12]

Although reason tells me that rewriting with rust may improve performance compatibility and maintainability. But some people clamoring to rewrite everything with rust does make me a bit annoyed.

If you're not writing the code, why does it matter? Some day one package will be switched for another package with a symlink and you're probably never notice.

[jacob]

https://github.com/uutils/coreutils/blob/0.0.26/Cargo.lock

Holy modularity, Batman! You weren't kidding!

On one hand, having more small modules as opposed to fewer big ones means that any given module is likely more easily auditable, but on the other hand, the sheer number of modules makes the likelihood of an XZ Utils incident too high for my liking. Given how, well, core the coreutils are, if this gets widespread adoption, every module in that list is an XZ begging for a malicious actor to try to take over.

The likelihood of an XZ-style attack in a Cargo-based project is extremely small. Look at that URL: for every dependency there is a checksum. If you trust the upstream developers of coreutils, then unless you voluntarily do "cargo update", then - hash collisions aside - you can be certain that if you build coreutils, it will use the same exact code in the dependencies as what upstream expects. From this point of view, it's actually far more secure than the C/C++-style dependency management where it simply tells you to download library XYZ (or a distro package) but, in the best of cases, it checks its version number, not its actual contents.

In fact if systemd was written in Rust and had its dependencies managed by cargo, the XZ attack wouldn't have worked (the XZ crate's checksum wouldn't match).

[alshdavid]

For me, the big win is how much easier it is to build Rust projects across operating systems and CPU architectures.
Having uutils support Windows and available via GitHub (releases or sources) is also really convenient.

I still don't know where the gnu core utils sources are or if the sourceforge binaries for Windows are malware

[QwertyChouskie]

The likelihood of an XZ-style attack in a Cargo-based project is extremely small. Look at that URL: for every dependency there is a checksum. If you trust the upstream developers of coreutils, then unless you voluntarily do "cargo update", then - hash collisions aside - you can be certain that if you build coreutils, it will use the same exact code in the dependencies as what upstream expects. From this point of view, it's actually far more secure than the C/C++-style dependency management where it simply tells you to download library XYZ (or a distro package) but, in the best of cases, it checks its version number, not its actual contents.

In fact if systemd was written in Rust and had its dependencies managed by cargo, the XZ attack wouldn't have worked (the XZ crate's checksum wouldn't match).

The whole point with XZ was that "Jia Tan" built trust and got the malicious update shipped in many distros as a normal update. Checksums prevent MitM attacks, they mean nothing if you intentionally update to a new release that later turns out to be malicious. The Cargo ecosystem is absolutely vulnerable to an XZ-style attack, same as any package-based ecosystem where you might have packages maintained by a single person that doesn't get much scrutiny.

[darkonix]

https://github.com/uutils/coreutils/blob/0.0.26/Cargo.lock

Holy modularity, Batman! You weren't kidding!

On one hand, having more small modules as opposed to fewer big ones means that any given module is likely more easily auditable, but on the other hand, the sheer number of modules makes the likelihood of an XZ Utils incident too high for my liking. Given how, well, core the coreutils are, if this gets widespread adoption, every module in that list is an XZ begging for a malicious actor to try to take over.

Every project should develop their own libraries for absolute everything. That will improve security for sure. Including the standard library. We can not trust into someone else standard, can we? No, we can't. Neither should we trust the compiler, who knows what that thing generates? Home baked compilers everyone. And why would we trust in the operating system? Did we develop it ourselves? Excepting Linus Torvalds, we didn't! Not Invented Here(c) is the new/old paradigm.