"The alternative languages" - in this case you're talking about C, 99% of the time. So let's talk about that. Well written C code, especially for the purpose of writing and continuing to maintain mature GNU coreutils, is not a big risk in terms of CVE. Between having an inexperienced Rust developer and an extremely experienced C developer (who's been through all the motions), I'd say the latter is likely the safer op…
100% it's the safer option. The software with the best security track record of all time is written in C.
I would maybe not go that far, look at ADA, SPARK etc.
If the attacker can control newroot/etc/passwd they _still_ get getpwnam to return whatever userid they want. The solution is to not lookup --userspec=username:group inside the chrooted-space, but from outside. Also, hi how's things? :)
I struggle to find anything on this post that wouldn't be caught by some kind of unit test or manual review, especially when comparing with the GNU source for the coreutils. The whole coreutils rewrite is a terrible idea[1] and clearly being done in the wrong way (without the knowledge gained from the previous software). If you do a rewrite, you should fully understand and learn from the predecessor, otherwise youre…
welcome new systems programmers: unix is broken and you must write ugly non-pedagogical workarounds and do empirical testing. this is what reliable software and good software engineering actually is... surprise!@#%
Canonical's usage of uutils is likely for marketing. But the codebase itself was developed for fun, as an excuse for people to have a hands-on way to learn Rust back before Rust was even released, with a minor justification as being cross-platform. From the original README in 2013: Why? ---- Many GNU, linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to window…
>Canonical's usage of uutils is likely for marketing Currently their usage is actively worsening the security of their distro
These things were caught and basically all of them weren't covered by any test suite (not even GNU coreutils'). It's a bit bold to claim that it's actively worsening it when it's not an LTS.
If you don't want Canonical's packages, you should probably just be using Debian rather than Ubuntu. It's not 2008 anymore, stock Debian is quite user-friendly.
Worth noting is that in Debian experimental coreutils defaults to coreutils-from-uutils [0]. This came as a big surprise and as far as I can tell there's been no discussion. A Canonical developer seems to have unilaterally overwritten the coreutils package without discussing with the maintainer. All the package renames that are in Ubuntu aren't in Debian so you can't switch to GNU utils either without deep trickery i…
The GPL prevents you from reading the licensed code before writing related non-GPL code? Which section of the GPL says that?
It's based on an interpretation of "derived from". It does not matter if it's in the GPL explicitly or not since we're talking about uutils and their stance on it, and they've written that: https://github.com/uutils/coreutils/blob/6b8a5a15b4f077f8609... > we cannot accept any changes based on the GNU source code [..]. It is however possible to look at other implementations under a BSD or MIT license like Apple's impl…
"we cannot accept any changes based on the GNU source code" is false. They are choosing not to accept it.
Nobody disputes that Rust is one of the programming languages that prevent several classes of frequent bugs, which is a valuable feature when compared with C/C++, even if that is a very low bar. What many do not accept among the claims of the Rust fans is that rewriting a mature and very big codebase from another language into Rust is likely to reduce the number of bugs of that codebase. For some buggier codebases, a…
As other people have mentioned, the goal of uutils was not "let's reduce bugs in coreutils by rewriting it in Rust", it was "it's 2013 and here's a pre-1.0 language that looks neat and claims to be a credible replacement for C, let's test that hypothesis by porting coreutils, giving us an excuse to learn and play with a new language in the process". It seems worth emphasizing that its creation was neither ideological…
> its creation was neither ideologically motivated nor part of some nefarious GPL-erasure scheme
No, they openly refuse to accept any GPL code. And even have a strict policy of not even reading GPL code.
I have to partially disagree with applying Hyrum's law here. In the case of core utils, there's not just the common GNU version. There's also what POSIX says they should do and what the various BSD does, plus some other implementations from various vendors that we mostly forget about. If in any case what this version of Core Utils does is different from what GNU does in a way that others are also different, it would…
But if you seek to replace coreutils (as at least is the case with Canonical it seems), rather than just be another POSIX userland implementation (e.g. busybox), then I would suggest you do need to be bug-compatible? I can apt/dnf/apk install busybox and use that for my user rather than coreutils, but given a significant amount of Linux infrastructure (including likely many personal scripts) are tied to coreutils, the bar is much higher. Given the numerous issues with quality Canonical has had, not just with Ubuntu but their other "commercial" tooling, I'm not sure any rewrite/port, written in rust or otherwise, with Canonical developing, managing, or even being associated with the project can meet the requisite bar.
The correct comparison to someone asking for first-party access to a C syscall is to the first-party crate that provides direct bindings to C syscalls. If you're willing to go further afield to third-party crates, you might as well skip rustix's "POSIX-ish" APIs (to quote their documentation) and go directly to the openat crate, which provides a Rust-style API.
If I have to use unsafe just to open a file, I might as well use C. While Rustix is a happy middle that is usually enough and more popular than the open at crate, libc is in the same family as the "*-sys" crate and, generally speaking, it is not intended for direct use outside other FFI crates.
I agree it’d be nice if there were a safe stdlib openat API, but
> If I have to use unsafe just to open a file, I might as well use C.