2 ms·

Not just the toolchain, I want to see a vetted library collection. Make it annual releases, "Rusty MetaLib 2023" which packages a majority of the standard playe

Not just the toolchain, I want to see a vetted library collection. Make it annual releases, "Rusty MetaLib 2023" which packages a majority of the standard players (regex, clap, num_cpus, SQLite, serde, time, etc). I have minimal Rust experience, but I really enjoy nearly everything about it. Except for the large dependency trees I am likely to pull in when building something more complicated than Hello World. Impossible to feel safe that all of that code has not been compromised.

timmclean 3y ago
For supply chain security, you might be interested in cargo-vet[0], a tool for coordinating and requiring manual reviews of open source dependencies. Both Mozilla and Google[1] have started publishing their audits.toml files, which are machine-readable files describing what source code reviews they have performed. [0] https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet [1] https://opensource.googleblog.com/2023/05/open-sourcing-our-rust-crate-audits.html https://opensource.googleblog.com/2023/05/open-sourcing-our-...
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.

timmclean 3y ago

For supply chain security, you might be interested in cargo-vet[0], a tool for coordinating and requiring manual reviews of open source dependencies. Both Mozilla and Google[1] have started publishing their audits.toml files, which are machine-readable files describing what source code reviews they have performed. [0] https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet [1] https://opensource.googleblog.com/2023/05/open-sourcing-our-rust-crate-audits.html https://opensource.googleblog.com/2023/05/open-sourcing-our-...

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.