4 ms·
The crates are very granular. They are almost used like modules in other languages. And procedural macros currently require a separate crate. My point is that y
by galangalalgol 3y ago
The crates are very granular. They are almost used like modules in other languages. And procedural macros currently require a separate crate. My point is that you probably have fewer authors than you think in those few hundred dependencies.
Second, the situation isn't appreciably better if you count by authors for c/c++. Running nm or whatever on a decent sized modern c++ thing is enlightening. Much of that is plastered over by the lack of a coherent package manager for those languages, so you end up using thebpackage manager for whatever distro your container is and you think "well thats all just RHEL stuff, I'm sure they vetted it"... but grpc by itself has a dozen or so dependencies not counting the ones it expects from the os. And that is a long list too. So we are in this situation with any language. Rust just makes it easy to see, which is good.
Cargo deny can block your pipeline on cves (or a license you don't want) popping up in your dependency tree. If you pin to a hash, and stick with it until you need a new feature or a cve appears, then that is about as safe as you can be right now. Austral has granular permissions for packages which would be even better, but it isn't here yet.
Lastly, the list of crates that get used to build rust itself is quite long, and I would presume some paths through those libraries got very closely inspected for the certification. Crates like tokio and clap and yesh num-cpus.