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

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