Rust-Written Coreutils Increases GNU Compatibility, Adds NetBSD Support

[Developer12]

you have to choose who you trust knowing that nothings infallible. given the numerous malware attacks in repos. I choose to trust projects that establish a trackrecord, and show care for the role their software is. certainly something that runs as root has a higher bar for me then software that doesn't. I just don't see a compelling reason to abandon coreutils/toybox for software that is a fast moving target just for some memory safety. I don't think vendoring in a bunch of libraries is a good solution, I rather then write the code themselves, just like busybox/toybox/coreutils. This is coreutils, which for me should be maintained by people with a particular knowledge of the systems that it runs upon. if you look at toybox development, you'll see they work very closely with android developers which is one of the major user of toybox. That builds confidence that they Rob has earned the trust of a major distributor and works to build a *boring* core userspace utilities for google and others.

When you write the implementation yourself, you have to do all the work of finding it's bugs. If you don't think there are any left, you just haven't found them yet.

Boring only means you're oblivious to the problems that still remain. How many people have actually bothered to look for security vulnerabilities in toybox's command line parsing? link traversal?

Vendoring code from the same place as everyone else means having help to find problems and get them fixed. "many eyes make all bugs shallow" -Torvalds

[waxhead]

Do not people understand that if you have a well tested software and rewire that in any language really, then while an off by one error overwriting an array might be caught there is no guarantee for the structural behavior of the program being sane.

Let's say the programmer forgets to treat tab as a whitespace under certain conditions (double tab) for example, if you pipe the output through a couple of programs (not uncommon in *nix) a new version of any program with a problem like the tab bug example that the original program did not have may result in corrupted data elsewhere in the system (just imagine wc as an example)

Yes this is a risk with all software regardless of language/version/revision etc, but in my opinion renders the rust Vs C problem mostly irrelevant. A buffer overrun you never hit its not a problem, likewise a super safe program is useless if it in those rare situations produces garbage from time to time. Both are bugs that can corrupt data or make issues elsewhere. It's simply a bug that should and will be fixed or worked around if people are interested enough.

[lowflyer]

I am wondering where this urge to rewrite a project in Rust comes from, may be from the original desire to write it in C?

That alone doesn't explain it. Add a healthy dose of C++ hatred and a blind admiration of Linus' ramblings to it, you'll get a viable explanation.

[dragonn]

When compiling a Rust project, the most recent version of each dependency that satisfies the version constraints is pulled down. That could be the latest-and-greatest release, or a release from years and years ago, or maybe even multiple, conflicting releases. (Dependencies might share dependencies but constrain them differently.)

Loose constraints are helpful in that they make updates more or less automatic, but they're harmful for audits and build reproducibility, and might introduce new and different bugs as easily as they might fix them.

No, or at least it depends. If a project does publish the Cargo.lock file with many projects do you get the exact same versions of all deps as the other developer when he was writing and testing/using them. uutils does have them in the repo, so they is no automatic updating of dependencies, it only happens when you explicitly run "cargo update".
And as far I know more or less happens the same happens when you vendor packages with cargo vendor. So they is no harm for audits and build reproducibility

[bug77]

There are 14 competing languages? Ridiculous! We need to develop one universe language that covers everyone's use cases.

While that is obviously not an option, I think it may be possible to come up with a tiered solution. Create a language and compiler good enough for systems programming and add everything else on top of that as optional language extensions, abstractions and compiler modules.
Imho, the more we concentrate on learning the underlying concepts and the less we fixate on languages and syntax, the better off we are.

[oleid]

By taking the RAD road, uutils is losing the single biggest advantage Rust has to offer — memory-safety — leaving it in the same nebulous bug boat as its predecessor, without its predecessor's decades of realworld usage, testing, and battle-hardening.

Are you trying to spread FUD or why are you suggesting that using external dependencies in rust will lead to questionable memory safety?

For example it is quite easy to check which of your dependencies are using unsafe blocks by using cargo geiger.

It is reasonable to assume that the authors of a safety critical create like this put some thought into to use or not to use those dependencies.

[oleid]

Loose constraints are helpful in that they make updates more or less automatic, but they're harmful for audits and build reproducibility, and might introduce new and different bugs as easily as they might fix them.

That's why you typically check in the Cargo.lock file. And update it to fix bugs or security issues. Cargo audit helps you with this.

[oleid]

Do not people understand that if you have a well tested software and rewire that in any language really, then while an off by one error overwriting an array might be caught there is no guarantee for the structural behavior of the program being sane.

That's why this coreutils replacement is developed using the test suite of the original project. That helps to get the structural behaviour right.

[jstoik]

Are you trying to spread FUD or why are you suggesting that using external dependencies in rust will lead to questionable memory safety?

I'm only suggesting that they can and occasionally do.

Memory-related CVEs have been assigned to dependencies of this project in the past. I'm pretty sure they were all quickly resolved, but they happened nonetheless.

This project also has a number of C dependencies. There's nothing Rust can do to ensure they function soundly.

It is reasonable to assume that the authors of a safety critical crate like this put some thought into to use or not to use those dependencies.

I wouldn't personally make that assumption, but it doesn't really matter.

The current number and nature of dependencies for this project make me uncomfortable. [Emphasis added for clarity.]

If you feel differently, that's A-OK! There are plenty of forks to go around.

[jstoik]

If a project does publish the Cargo.lock file with many projects do you get the exact same versions of all deps as the other developer when he was writing and testing/using them.

I had understood the original question to imply that "cargo update" would be run. But if not, then you are correct, nothing would change for the parent crate unless the lock itself were to change.