GNU Coreutils 9.2 - Now Avoids cp/mv Allocating Too Much Memory

[ultimA]

God you people need to stop it with the irrelevant apologizing for legacy code bases. It only takes one single memory based bug to cause a security incident. Period. ONE.

Which is exactly why you don't go reimplementing huge well-audited codebases that never really had quality problems in the past. Even if you eliminate memory bugs, you'll be introducing more security flaws due to other mistakes. Well, not generally, many software do have more memory bugs than logic bugs, but this in no way looks like the case for coreutils.

While it's true that Rust does not by itself solve all logic problems, there's an added benefit of taking an old code base and working out the logic to it which can identify flaws others have missed.

You really think nobody has done this for the tools in coreutils yet? I wonder how those few CVEs got discovered then...

He simply said he switched coreutils... You are the one that looks fanatical here...

What he did was recommend for users to switch to a software with no audits, no performance or proven security benefits, less platform support, less features and less testing, just because it is written in Rust. That's non-sensical. But yes, admittedly I am already pre-annoyed by fan posts. Exactly due to posts like his.

[mdedetrich]

Polished turds don't taste any better I hear though.

Evidently we are missing out

[Weasel]

God you people need to stop it with the irrelevant apologizing for legacy code bases. It only takes one single memory based bug to cause a security incident. Period. ONE. That's literally (in the true and traditional sense of literal) statistically inevitable with C or C++. End of story.

Nobody gives a flying fuck if such "security incident" is so rare or can only happen under extreme circumstances, such as attacker having root access to your machine already. End of story.

Then you have actual security incidents that say, have a filesystem race condition, which can be exploited by unprivileged users if you run cp as root for example, which Rust doesn't protect against one bit. This kind of things are the actual real problems dumbass, and they require careful auditing and reasoning. Something which your Rust toy does not have.

So stop spewing that garbage.

[archkde]

Then you have actual security incidents that say, have a filesystem race condition, which can be exploited by unprivileged users if you run cp as root for example, which Rust doesn't protect against one bit. This kind of things are the actual real problems dumbass, and they require careful auditing and reasoning. Something which your Rust toy does not have.

Functions in the standard library that iterate over the file system are carefully written to avoid security issues stemming from race conditions, so Rust actually does offer some (not full) protection here.

[cb88]

While that can be seen as an advantage, that's not even the reason why it exists. The project author has publicly stated uutils exists because he wanted to get practice using Rust. That's all. He had no problems with coreutils' performance or security or with whatever aspect, he was just basically bored and interested in getting some practice.

And then fanbois jump in and start recommending it over Coreutils that has been tested and scrutinized for decades, has been working exceptionally well for everybody, and is actively maintained by an experienced group of people. That's Rust-fan logic.

Scrutinized for decades and still has bugs... anyway. As soon as he can fully pass the coreutils test suite (about halfway there currently) it will probalby have surpassed the GNU utils in every way. That's because technically he is reusing a huge part of the work from coreutils and that is the testsuite....

[Nth_man]

[...] The article and thus this thread is about the new version and the new capabilities of Coreutils 9.2. Does your alternative already support the same features? [...]

Something bloating worse:

https://archlinux.org/packages/core/x86_64/coreutils/ Installed Size: 15.3 MB
https://archlinux.org/packages/commu...ils-coreutils/ Installed Size: 32.3 MB
-- https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1371662-the-rust-implementation-of-gnu-coreutils-is-becoming-remarkably-robust?p=1371851#post1371851

The most notable thing about this project is it allows proprietarization, while GNU coreutils doesn't.
-- https://github.com/uutils/coreutils/issues/1781

[caligula]

Something bloating worse:
https://archlinux.org/packages/core/x86_64/coreutils/ Installed Size: 15.3 MB
https://archlinux.org/packages/commu...ils-coreutils/ Installed Size: 32.3 MB

Indeed. The old binaries are about 5,2 MiB in size, the new one is a single 32 MiB bin. Busybox also packs everything in a single binary, which reduces the size even further. So the actual production code in something like 6 or 7 times larger in the Rust executable.

[Weasel]

Functions in the standard library that iterate over the file system are carefully written to avoid security issues stemming from race conditions, so Rust actually does offer some (not full) protection here.

Wow you're dumb as a brick if you thought I was talking about the functions themselves being atomic or not. I'm talking about higher level things (read the CVEs for GNU coreutils) which Rust offers ZERO extra protection for compared to C (so it's the same).

For example, "find" has to enter directory before operating in it, else you risk race condition where attacker can replace a path with a symlink. If you run find as root and do something with it, you'll give out such privileges to attacker if he can abuse it. This is just an easy example of course, there's plenty of others.

Such things require careful auditing. Rusted brains think that programming is a toy and such things don't exist after all, just memory bugs!!!

[kn00tcn]

can we just get a progressbar during those move/copy operations? it seems ridiculous that this request was closed years ago due to the tools being 'feature complete', yet they are still getting updates

a feature is still a feature whether it's user facing or employing a kernel function, why deny the obvious one, not everything is on an ssd, not everything is <1gb, this was needed decades ago