| ▲ | anuramat 3 hours ago |
| > supply chain risk how is rust special in this regard? |
|
| ▲ | bitbasher 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. 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... |
| |
| ▲ | afdbcreid 2 hours ago | parent | 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. | | |
| ▲ | bitbasher 2 hours ago | parent [-] | | 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! |
| |
| ▲ | anuramat an hour 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 | |
| ▲ | dochtman 2 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. | |
| ▲ | tcfhgj 2 hours ago | parent | prev [-] | | I think none of this is special to Rust vs C++, except #4, because C++ doesn't have an equivalent | | |
| ▲ | bitbasher an hour ago | parent [-] | | 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. |
|
|
|
| ▲ | selfmodruntime 40 minutes ago | parent | prev | next [-] |
| It really isn't and AFAIK there has been little if any supply chain compromise in Rust code as of now |
|
| ▲ | galangalalgol 2 hours ago | parent | prev [-] |
| In languages that don't have a culture of deep dependency trees managed with good tooling, supply chain attacks are perceived as being more difficult or rarer. That may or may not be true. But it is a concern in any case. Rust could have had namespaces to decrease namesquatting. The "no deps younger than N days" thing will help some. Those with this perception would prefer a large stdlib that is well vetted or that they can pretend is well vetted. In practice, if you don't use tokio you are likely not using anything that isn't written by a well known member of the rust community. Tokio brings in a lot... The real fix comes in two flavors, pay to write everything yourself and test it well. Or limit what a bad dependency can do. The latter is difficult in every mainstream language. Austral had a good answer for it, but seems to be dead. |
| |
| ▲ | anuramat 2 hours ago | parent [-] | | > austral thanks, can't believe the idea isn't more mainstream -- I've never thought dependency safety could be a thing | | |
| ▲ | galangalalgol an hour ago | parent [-] | | In rust if you can verify a dependency is no_std with no unsafe code and that all of it's dependencies are the same, then it can't get to libc or the kernel syscalls. So any privilege it works with is something you passed it. But that amounts to writing everything yourself in practice. |
|
|