| |
| ▲ | vsgherzi 32 minutes ago | parent | next [-] | | I'm sympathetic to the supply chain problem I even wrote a whole thing on it https://vincents.dev/blog/rust-dependencies-scare-me/ That being said as many above have pointed out you can choose not to bring in dependencies. The Chrome team already does this with the font parser library they limit dependencies to 1 or 2 trusted ones with little to no transitive dependencies. Let's not pretend C / C++ is immune to this we had the xz vuln not too long ago. C / C++ has the benefit of the culture not using as many dependencies but this is still a problem that exists. With the increase of code in the world due to ai this is a problem we're going to need to fix sooner rather than later. I don't think the supply chain should be a blocker for using rust especially when once of the best C++ teams in the world with good funding struggles to always write perfect code. The chrome team has shown precedent for moving to rust safely and avoiding dependency hell, they'll just need to do it again. They have hundreds of engineers many of which are very gifted, hell they can write their own dependencies! | |
| ▲ | cogman10 3 hours ago | parent | prev | next [-] | | If you can bring in 3rd party libraries, you can be hit with a supply chain attack. C and C++ aren't immune, it's just harder to pull off due to dependency management being more complex (meaning you'll work with less dependencies naturally). | | |
| ▲ | jacquesm 15 minutes ago | parent | next [-] | | It's not more complex in C or C++, you just have less of a culture of buying into a whole eco-system. C and C++ play nice with the build system that you bring, rather than that you are forced into a particular way of working. It's 'just a compiler' (ok, a bit more than that). I don't need to use a particular IDE, a particular build system, a particular package manager or even a particular repository. That is not to throw shade on those other languages, each to their own, but I just like my tools to stay in their lane. Just like I have a drawer full of different hammers rather than one hammer with 12 different heads, a screwdriver, a hardware store and a drill attachment. I wouldn't know what to do with it. | |
| ▲ | skydhash 2 hours ago | parent | prev [-] | | You’ll find more quality libraries in C because people don’t care about splitting them down to microscopic parcels. Even something like ‘just’ have tens of deps, including one to check that something is executable. https://github.com/casey/just/blob/master/Cargo.toml That’s just asking for trouble down the line. | | |
| ▲ | bigfatkitten 2 hours ago | parent | next [-] | | You also won’t typically find C/C++ developers blinding yolo’ing the latest version of a dependency from the Internet into their CI/CD pipeline. They’ll stick with a stable version that has the features they need until they have a good reason to move. That version will be one they’ve decided to ship themselves, or it’ll be provided by someone like Debian or Red Hat. | | |
| ▲ | pjmlp 27 minutes ago | parent [-] | | Unless of course they are using vcpkg, conan or FetchContent. Most corporations are already using the likes of Nexus or JFrog Artifactory, regardless of the programming language. |
| |
| ▲ | pheggs 2 hours ago | parent | prev [-] | | yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though | | |
| ▲ | kibwen 18 minutes ago | parent | next [-] | | > both of these are not the case in practice though No, people routinely write Rust with no third-party dependencies, and yet people do not routinely write C code that is memory-safe. Your threat model needs re-evaluating. Also keep in mind that the most common dependencies (rand, serde, regex, etc) are literally provided by the Rust project itself, and are no more susceptible to supply chain attacks than the compiler. | |
| ▲ | dbdr 22 minutes ago | parent | prev [-] | | One difference is that it's an incredibly hard problem to check whether your C code is memory safe since every single line of your code is a risk. On the other hand, it's easy to at least assess where your supply vulnerabilities lie (read Cargo.toml), and you can enforce your policy of choice (e.g. whitelist a few specific dependencies only, vendor them, etc). |
|
|
| |
| ▲ | kibwen 3 hours ago | parent | prev | next [-] | | But this is irrelevant. If you're afraid of third-party code, you can just... choose not to use third-party code? Meanwhile, if I'm afraid of memory corruption in C, I cannot just choose not to have memory corruption; I must instead simply choose not to use C. Meanwhile, Chromium uses tons of third-party Rust code, and has thereby judged the risk differently. | | |
| ▲ | JoeAltmaier 3 hours ago | parent [-] | | Maybe it's more complicated than that? With allocate/delete discipline, C can be fairly safe memory-wise (written a million lines of code in C). But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for. By that point of view, we reverse the conclusion. | | |
| ▲ | nagaiaida 2 hours ago | parent | next [-] | | yes, people often invoke "simply write safer c" but that doesn't make it any more realistic of a proposition in aggregate as we keep seeing. | |
| ▲ | stackghost 2 hours ago | parent | prev [-] | | >With allocate/delete discipline, C can be fairly safe memory-wise (written a million lines of code in C) The last 40-50 years have conclusively shown us that relying on the programmer to be disciplined, yourself included, does not work. |
|
| |
| ▲ | staticassertion 4 hours ago | parent | prev [-] | | Google already uses `cargo-vet` for rust dependencies. | | |
| ▲ | pheggs 3 hours ago | parent [-] | | thats good, but it wont eliminate the risk | | |
| ▲ | staticassertion 3 hours ago | parent [-] | | Nothing eliminates the risk but it is basically a best-in-class solution. If your primary concern is supply chain risk, there you go, best in class defense against it. If anything, what are you doing about supply chain for the existing code base? How is cargo worse here when cargo-vet exists and is actively maintained by Google, Mozilla, and others? | | |
| ▲ | pheggs 2 hours ago | parent [-] | | true, but rusts success in creating an easy to use dependency manager is the curse. In general rust software seems to use a larger amount of dependencies than c/c++ due to that, where each is at risk of becoming an attack vector. my prediction is that we will see some abuse of this in future, similar to what npm experienced |
|
|
|
|
