| ▲ | bitbasher 5 hours ago | ||||||||||||||||
Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. 1. Each crate you depend on generally comes with dozens of its own dependencies. 2. A large number of crates have few downloads. You can use blessed.rs to try an find "trusted" dependencies. 3. Cargo comes with "build.rs" for compile time code execution. Basically, your code (or your dependencies) can run arbitrary code when it first gets compiled. 4. A Github account is required to publish crates to crates.io (this sucks if you don't want to be locked in to another Microsoft system). These are just a few of the issues I have had with Rust before switching off it. edit: Point #4 is personal for me. I have multiple crates published on crates.io and I cannot log in and manage them because I deleted my GitHub account a long time ago. I wonder if someone could create a GitHub account using my name and claim ownership of them... | |||||||||||||||||
| ▲ | okanat 2 hours ago | parent | next [-] | ||||||||||||||||
> Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. This is no different than C++. C++ standard library made so many compromises in the name of ABI compatibility almost none of the library is actually usable for any use case. So people start to quickly add things like boost, abseil, folly, Qt, asio, imgui, doctest etc. There are millions of small libraries everywhere too! Their CMakeLists files or conan packages also execute random commands and in the case of supply chain compromise they are as vulnerable as Rust. Actually CMake is so complicated that one can hide an exploit a bit better than build.rs. I don't think it is a good thing either way and both toolchains should implement ways to limit execution and isolate code generation. For the packages we also need to see stronger ownership and signing guarantees. Maybe even a domain-based validation system with TXT-keys against takeovers. Allowing random people to just register and typosquat packages is not a good idea. | |||||||||||||||||
| ▲ | afdbcreid 5 hours ago | parent | prev | next [-] | ||||||||||||||||
As for #4, you will probably be interested in https://github.com/rust-lang/crates.io/issues/326. The crates.io team wants this, but this is complex to implement and they're understaffed. | |||||||||||||||||
| |||||||||||||||||
| ▲ | dochtman 5 hours ago | parent | prev | next [-] | ||||||||||||||||
> I wonder if someone could create a GitHub account using my name and claim ownership of them... AIUI the crates are actually linked to the account via a different identifier, not directly to the username. | |||||||||||||||||
| ▲ | anuramat 4 hours ago | parent | prev | next [-] | ||||||||||||||||
again, I don't really see how 1 and 2 are rust specific; compared to c -- sure, but it's seems unfair: the type of rust software that needs a bunch of random dependencies usually wouldn't even exist in c in the first place; if it would, then it's more of a software quality problem than security even 4 -- fuck microsoft of course, but other than that: you always need some sort of an account to publish stuff | |||||||||||||||||
| ▲ | tcfhgj 5 hours ago | parent | prev [-] | ||||||||||||||||
I think none of this is special to Rust vs C++, except #4, because C++ doesn't have an equivalent | |||||||||||||||||
| |||||||||||||||||