4 ms·

I find it interesting how people will criticise Rust for not preventing all bugs, when the alternative languages don't prevent those same bugs nor the bugs rust

I find it interesting how people will criticise Rust for not preventing all bugs, when the alternative languages don't prevent those same bugs nor the bugs rust does catch. If you're comparing Rust to a perfect language that doesn't exist, you should probably also compare your alternative to that perfect language as well right? I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at the start of its lifetime, and compare it with this rewrite. Same with the number of memory bugs that are impossible in (safe) Rust. Don't just downvote me, tell me how I'm wrong.

throawayonthe 6mo ago
i don't think CVEs were a thing at the start of the GNU rewrite
flohofwoe 6mo ago
What's the point of a "rewrite in Rust" when it introduces bugs that either never existed in the original or were fixed already? > I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at the start of its lifetime The point is, those bugs had been discovered and fixed decades ago. Do you want to wait decades for coreutils_rs to reach the same robustness? Why do a rewrite when the alternative is to help improve the original which is starting from a much more solid base? And even when a complete rewrite would make sense, why not do a careful line-by-line porting of the original code instead of doing a clean-room implementation to at least carry over the bugfixes from the original? And why even use the Rust stdlib at all when it contains footguns that are not acceptable for security-critical code?
- slopinthebag 6mo ago
  Idk, you should ask the maintainers these questions, or the Ubuntu maintainers. I'm not particularly arguing in favour of this rewrite, but the title and contents of the post are talking about Rust in general and the type of bugs it can/can't prevent. Perhaps one good reason is that once the initial bugs are fixed, over time the number of security issues will be lower than the original? If it could reach the same level of stability and robustness in months or a small number of years, the downsides aren't totally obvious. We will have to wait to judge I suppose. Maybe it's not worth it and that's fine, but it doesn't speak to Rust as a language.
- adrian_b 6mo ago
  The Rust developers have not read the original coreutils, because they want to replace the GPL license, so they want to be able to say that their code is not derived from the original coreutils. For a project of this kind, this seems a rather stupid choice and it is enough to make hard to trust the rewritten tools. Even supposing that replacing the GPL license were an acceptable goal, that would make sense only for a library, not for executable applications. For executable applications it makes sense to not want GPL only when you want to extract parts of them and insert them into other programs.
  - estebank 6mo ago
    > For executable applications it makes sense to not want GPL only when you want to extract parts of them and insert them into other programs. It is very common for applications written in Rust to be split in multiple reusable crates. Looking at the main crate, that is the case here too: https://crates.io/crates/coreutils/0.8.0/dependencies https://crates.io/crates/coreutils/0.8.0/dependencies This allows for the learnings of uutils (and by extension GNU coreutils) to be able to be leveraged by any other project that needs the same functionality. I noticed on a quick scan of the dependents on uucore that other projects (like nushell) do so.
- empath75 6mo ago
  > What's the point of a "rewrite in Rust" when it introduces bugs that either never existed in the original or were fixed already? Because you are trying to remove memory safety as a source of bugs in the future. No code is bug free, but removing entire categories of bugs from a code base is a good thing.
kubb 6mo ago
You’re right, but it’s gonna be hard to stop them from raging. In many ways people want to be justified in a „see, I told you so, Rust is useless” belief, and they’re willing to take one or two questionable logical steps to get there.
sgt 6mo ago
"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 option.
- geocar 6mo ago
  100% it's the safer option. The software with the best security track record of all time is written in C.
  - sgt 6mo ago
    I would maybe not go that far, look at ADA, SPARK etc.
  - foobar1274278 6mo ago
    I'm curious which software you have in mind. Ex: seL4 is technically C, but I'd say the theorem prover is doing most of the real work there.
    - geocar 6mo ago
      Specifically? I'm thinking of qmail. qmail was at one point the second most widely deployed email server, handling the majority of online mail. It wasn't a research project; it's not obscure. Yahoo used to use it. And what I mean by track record: After more than a decade after the last published version, a theoretical attack was found requiring special setup uncommon for a sysadmin, and impossible ten years prior. When anyone thinks about how to build reliable secure software, I think they should be thinking of qmail because it really has no public source-available equal, except maybe djbdns. seL4 on the other hand makes some specious claims about some ten year old version of itself, and so few people have even heard about it you thought it important to remind it is "technically" C -- qmail isn't like that at all: There is no prover, no test suite, and almost no metaprogramming of any kind. It's just C.

throawayonthe 6mo ago

i don't think CVEs were a thing at the start of the GNU rewrite

flohofwoe 6mo ago

What's the point of a "rewrite in Rust" when it introduces bugs that either never existed in the original or were fixed already? > I'd be interested in a comparison with the amount of bugs and CVE's in GNU coreutils at the start of its lifetime The point is, those bugs had been discovered and fixed decades ago. Do you want to wait decades for coreutils_rs to reach the same robustness? Why do a rewrite when the alternative is to help improve the original which is starting from a much more solid base? And even when a complete rewrite would make sense, why not do a careful line-by-line porting of the original code instead of doing a clean-room implementation to at least carry over the bugfixes from the original? And why even use the Rust stdlib at all when it contains footguns that are not acceptable for security-critical code?

slopinthebag 6mo ago
Idk, you should ask the maintainers these questions, or the Ubuntu maintainers. I'm not particularly arguing in favour of this rewrite, but the title and contents of the post are talking about Rust in general and the type of bugs it can/can't prevent. Perhaps one good reason is that once the initial bugs are fixed, over time the number of security issues will be lower than the original? If it could reach the same level of stability and robustness in months or a small number of years, the downsides aren't totally obvious. We will have to wait to judge I suppose. Maybe it's not worth it and that's fine, but it doesn't speak to Rust as a language.
adrian_b 6mo ago
The Rust developers have not read the original coreutils, because they want to replace the GPL license, so they want to be able to say that their code is not derived from the original coreutils. For a project of this kind, this seems a rather stupid choice and it is enough to make hard to trust the rewritten tools. Even supposing that replacing the GPL license were an acceptable goal, that would make sense only for a library, not for executable applications. For executable applications it makes sense to not want GPL only when you want to extract parts of them and insert them into other programs.
- estebank 6mo ago
  > For executable applications it makes sense to not want GPL only when you want to extract parts of them and insert them into other programs. It is very common for applications written in Rust to be split in multiple reusable crates. Looking at the main crate, that is the case here too: https://crates.io/crates/coreutils/0.8.0/dependencies https://crates.io/crates/coreutils/0.8.0/dependencies This allows for the learnings of uutils (and by extension GNU coreutils) to be able to be leveraged by any other project that needs the same functionality. I noticed on a quick scan of the dependents on uucore that other projects (like nushell) do so.
empath75 6mo ago
> What's the point of a "rewrite in Rust" when it introduces bugs that either never existed in the original or were fixed already? Because you are trying to remove memory safety as a source of bugs in the future. No code is bug free, but removing entire categories of bugs from a code base is a good thing.

kubb 6mo ago

You’re right, but it’s gonna be hard to stop them from raging. In many ways people want to be justified in a „see, I told you so, Rust is useless” belief, and they’re willing to take one or two questionable logical steps to get there.

sgt 6mo ago

"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 option.

geocar 6mo ago
100% it's the safer option. The software with the best security track record of all time is written in C.
- sgt 6mo ago
  I would maybe not go that far, look at ADA, SPARK etc.
- foobar1274278 6mo ago
  I'm curious which software you have in mind. Ex: seL4 is technically C, but I'd say the theorem prover is doing most of the real work there.
  - geocar 6mo ago
    Specifically? I'm thinking of qmail. qmail was at one point the second most widely deployed email server, handling the majority of online mail. It wasn't a research project; it's not obscure. Yahoo used to use it. And what I mean by track record: After more than a decade after the last published version, a theoretical attack was found requiring special setup uncommon for a sysadmin, and impossible ten years prior. When anyone thinks about how to build reliable secure software, I think they should be thinking of qmail because it really has no public source-available equal, except maybe djbdns. seL4 on the other hand makes some specious claims about some ten year old version of itself, and so few people have even heard about it you thought it important to remind it is "technically" C -- qmail isn't like that at all: There is no prover, no test suite, and almost no metaprogramming of any kind. It's just C.