3 ms·

All I'm saying that in a maze of twisty little dependencies, all alike, it's very tedious to vet them all, and it's much too easy to end up with thousands of cr

All I'm saying that in a maze of twisty little dependencies, all alike, it's very tedious to vet them all, and it's much too easy to end up with thousands of crates for the simplest things. And it's very easy to put nefarious things in once there is a will to do so. It all works well if everyone wants to play nice, but this doesn't scale. I don't know if Rust has the same quirk as JS/npm where a project can transitively depend on several versions of a module and they can coexist. Imagine a crate fixing some nasty shit, but some transitive dependency still pinning a vulnerable version. I contrast this with Go that has a rich enough standard library so you rarely need a dependency, and you don't need any for mundane stuff, and it makes you think hard about every dependency you introduce. And they got burned early enough so vendoring is a Good Thing now. And then I compare it with Perl, in that on one hand, it has lots of core modules, but then its standard library is lacking in weird places making you reach for CPAN in 100% of the cases writing a non-trivial program (HTTP/TLS comes to mind), and it would be similar to Rust except that CPAN is very slow-paced these days. I'm curious to see how it all evolves.

steveklabnik 2y ago
> it's very tedious to vet them all, It is also very tedious to vet a large dependency, as there's so much code to review. > It all works well if everyone wants to play nice, but this doesn't scale. There are tools like cargo-crev to help scale up the "hey I reviewed the code here and if you trust me, you can trust my review." > I don't know if Rust has the same quirk as JS/npm where a project can transitively depend on several versions of a module and they can coexist. Yes, on purpose. Rust will try to unify them as much as possible, but if two dependencies rely on incompatible versions, you'll get two. Note that they'll be different types, so if you try and use a foov1 where a foov2 is needed, you'll get a compile error. > Imagine a crate fixing some nasty shit, but some transitive dependency still pinning a vulnerable version. This goes both ways: you could also have some code depending on an older, secure version, and a newer one is the one with the vulnerabilty. But also, the way you phrase this makes me think you may misunderstand some details about how this happens: each crate doesn't pin its own version, exactly. The entire dependency graph is looked at holistically. But as I said above, you can still get situations like this, so this is very nitpicky. > And they got burned early enough so vendoring is a Good Thing now. You can absolutely trivially vendor your Rust dependencies as well. It's built into the tooling. > I'm curious to see how it all evolves. Absolutely. Me too.

steveklabnik 2y ago

> it's very tedious to vet them all, It is also very tedious to vet a large dependency, as there's so much code to review. > It all works well if everyone wants to play nice, but this doesn't scale. There are tools like cargo-crev to help scale up the "hey I reviewed the code here and if you trust me, you can trust my review." > I don't know if Rust has the same quirk as JS/npm where a project can transitively depend on several versions of a module and they can coexist. Yes, on purpose. Rust will try to unify them as much as possible, but if two dependencies rely on incompatible versions, you'll get two. Note that they'll be different types, so if you try and use a foov1 where a foov2 is needed, you'll get a compile error. > Imagine a crate fixing some nasty shit, but some transitive dependency still pinning a vulnerable version. This goes both ways: you could also have some code depending on an older, secure version, and a newer one is the one with the vulnerabilty. But also, the way you phrase this makes me think you may misunderstand some details about how this happens: each crate doesn't pin its own version, exactly. The entire dependency graph is looked at holistically. But as I said above, you can still get situations like this, so this is very nitpicky. > And they got burned early enough so vendoring is a Good Thing now. You can absolutely trivially vendor your Rust dependencies as well. It's built into the tooling. > I'm curious to see how it all evolves. Absolutely. Me too.