I'd like to be able to pick a few libraries without incurring a huge ongoing audit burden. If I have to exclude many popular libraries because they have oodles of dependencies, that both makes searching more laborious and limits my choices.
I'd like to be able to pick a few libraries without incurring a huge ongoing audit burden. If I have to exclude many popular libraries because they have oodles of dependencies, that both makes searching more laborious and limits my choices.
Yes, knowing that would be helpful!
Is there a way to whitelist owners/publishers in Cargo?
There is really just a handful of crates that nearly often get pulled in and probably like 5 authors across them.
Supply chain harderning is pretty easy in rust: caro-deny, cargo-suply-chain, cargo-crev, cargo-vet, cargo-{s}bom and probably a few more I can't remember.
This starts from explaining outright which dependencies they have and why.
It's not so much direct dependencies that bother me: it's an exponential explosion of transitive dependencies.
Also, seeing an “end product” with dozens of dependencies doesn't bother me much; a library does.
Should every physics/ML/etc library have to write their own array abstractions and operators? If every networking library had to write and ship their own async executor logic, I can safely posit that would be about 100x worse than it is now.
The alternative to “zero dependencies” isn’t full “JS/NPM-dumpster-fire”.
So how many dependencies are there truly when you peel away the first layer of the onion?
The obvious answer is "N crates is N dependencies", because each crate represents a discrete sequence of atomic software release packages.
In the absence of a standardized mechanism to group crates together, we have to fall back to informal methods, like "I know all these authors personally because I'm an insider", or "these crates seem to be related even though I'm unsure how to guarantee they'll stay that way".
You can take a hard line and insist that nobody should run a single line of code they haven't reviewed, but that severely constrains the ability of a typical org to use the wider ecosystem at all. Not every org has the expertise on staff to pore over diverse Rust code and confidently state that it has no issues, and even those that do have to consider whether paying that cost is good risk management.
It would be nice if there was a more reliable way to simplify the evaluation of publisher trust centers, especially for orgs who aren't going to audit code but don't want to blindly take in anything.