4 ms·

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

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

dochtman 4mo ago
> 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.
afdbcreid 4mo ago
As for #4, you will probably be interested in https://github.com/rust-lang/crates.io/issues/326 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.
- bitbasher 4mo ago
  I've seen it, but it's from 2016. They have known about the issue for a 10+ years and haven't fixed it yet... seems unlikely to change! Maybe some day though!
tcfhgj 4mo ago
I think none of this is special to Rust vs C++, except #4, because C++ doesn't have an equivalent
- bitbasher 4mo ago
  Most dependencies in the C/C++ world come with fewer dependencies of their own (at least, an order of magnitude fewer than the average rust dependency). Perhaps a Makefile could be considered arbitrary code execution, but we've been running Makefiles for 50 years and we haven't had the supply chain issues we see in NPM, etc. Supply chain risk was always considered in the C/C++ world... think back to Ken Thompson's 1984 paper "Reflections on Trusting Trust" where he questioned if you could even trust your compiler. Perhaps the main difference between the Rust and C/C++ world is less about the tooling or languages, but more cultural? I don't know, just something to think about.
  - dralley 4mo ago
    But how often do people just copy and paste code in the C/C++ ecosystem? Or reimplement things badly? Last I checked VLC had a homegrown XML parser.
    - armitron 4mo ago
      Experts know that copy/pasting and/or reimplementing code is not an issue in practice regardless of how often it comes up as an anti-pattern in freshman CS courses. The (amalgamated) software system can still be audited in reasonable time as long as the number of third party dependencies is kept low. Rust has thrown the baby out with the bathwater in that regard resulting in software that is practically impossible to audit without putting in enormous effort.
- pjmlp 4mo ago
  In 2026 it does, vcpkg and conan.
  - tcfhgj 4mo ago
    the fact that you mention two options, shows already that C++ doesn't have an equivalent
anuramat 4mo ago
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
okanat 4mo 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. 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.
- armitron 4mo ago
  I've never seen a C program use hundreds of dependencies. This is typical in Rust (and Node). I know a few high assurance teams that dropped Rust for this very reason.
  - dwattttt 4mo ago
    I haven't seen hundreds of dependencies in C projects either. But I _have_ seen on the scale of 1s to 10s of libraries and algorithms vendored in (sometimes just a header or 5). It's also an indirect risk, but I've seen C projects reimplement things that would be a dependency in Rust, and introduce subtle (or not subtle) bugs.
  - pjmlp 4mo ago
    Because most of them depend on UNIX being there in first place, aka all of POSIX, alongside Khronos APIs. Additionally, most C libraries tend to come via UNIX package managers directly, and then consumed via CMake, pkg-config or what not. I do agree Rust dependency trees are a problem, for security, and always compiling everything from source.
  - 4mo ago
saghm 4mo ago
> 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... Why not just make a throwaway account with that username and test it, and if it works, just don't save the password or ever log on again? If it's something you care about personally and it's really been that long, I'm kind of confused why you haven't already tried this rather than just vaguely implying risk that seems pretty straightforward too verify. (It's fine if you just legitimately don't care, but it doesn't seem like it's really a personal issue for you in that case)

dochtman 4mo ago

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

afdbcreid 4mo ago

As for #4, you will probably be interested in https://github.com/rust-lang/crates.io/issues/326 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.

bitbasher 4mo ago
I've seen it, but it's from 2016. They have known about the issue for a 10+ years and haven't fixed it yet... seems unlikely to change! Maybe some day though!

tcfhgj 4mo ago

I think none of this is special to Rust vs C++, except #4, because C++ doesn't have an equivalent

bitbasher 4mo ago
Most dependencies in the C/C++ world come with fewer dependencies of their own (at least, an order of magnitude fewer than the average rust dependency). Perhaps a Makefile could be considered arbitrary code execution, but we've been running Makefiles for 50 years and we haven't had the supply chain issues we see in NPM, etc. Supply chain risk was always considered in the C/C++ world... think back to Ken Thompson's 1984 paper "Reflections on Trusting Trust" where he questioned if you could even trust your compiler. Perhaps the main difference between the Rust and C/C++ world is less about the tooling or languages, but more cultural? I don't know, just something to think about.
- dralley 4mo ago
  But how often do people just copy and paste code in the C/C++ ecosystem? Or reimplement things badly? Last I checked VLC had a homegrown XML parser.
  - armitron 4mo ago
    Experts know that copy/pasting and/or reimplementing code is not an issue in practice regardless of how often it comes up as an anti-pattern in freshman CS courses. The (amalgamated) software system can still be audited in reasonable time as long as the number of third party dependencies is kept low. Rust has thrown the baby out with the bathwater in that regard resulting in software that is practically impossible to audit without putting in enormous effort.
pjmlp 4mo ago
In 2026 it does, vcpkg and conan.
- tcfhgj 4mo ago
  the fact that you mention two options, shows already that C++ doesn't have an equivalent

anuramat 4mo ago

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

okanat 4mo 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. 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.

armitron 4mo ago
I've never seen a C program use hundreds of dependencies. This is typical in Rust (and Node). I know a few high assurance teams that dropped Rust for this very reason.
- dwattttt 4mo ago
  I haven't seen hundreds of dependencies in C projects either. But I _have_ seen on the scale of 1s to 10s of libraries and algorithms vendored in (sometimes just a header or 5). It's also an indirect risk, but I've seen C projects reimplement things that would be a dependency in Rust, and introduce subtle (or not subtle) bugs.
- pjmlp 4mo ago
  Because most of them depend on UNIX being there in first place, aka all of POSIX, alongside Khronos APIs. Additionally, most C libraries tend to come via UNIX package managers directly, and then consumed via CMake, pkg-config or what not. I do agree Rust dependency trees are a problem, for security, and always compiling everything from source.
- 4mo ago

saghm 4mo ago

> 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... Why not just make a throwaway account with that username and test it, and if it works, just don't save the password or ever log on again? If it's something you care about personally and it's really been that long, I'm kind of confused why you haven't already tried this rather than just vaguely implying risk that seems pretty straightforward too verify. (It's fine if you just legitimately don't care, but it doesn't seem like it's really a personal issue for you in that case)