Determine plan for auditing Rust dependencies

[legoktm]

As part of using Sequoia, we'll start pulling in Rust dependencies (161 crates by my current count!). The process for performing "diff reviews" of Python dependencies is documented on the wiki.

We may want to take advantage of some Rust tools that allow for sharing audit status like:

• https://github.com/crev-dev/cargo-crev
• https://github.com/mozilla/cargo-vet (see LWN coverage: https://lwn.net/Articles/897435/)

[legoktm]

I reviewed both the cargo-crev and cargo-vet documentation, and while it seems less mature, my preference is for cargo-vet.

cargo-crev is designed for individuals doing reviews, each person gets a crev ID and hosts their own crev proof repository. While cargo-vet seems more aligned with trusting orgs for reviews.

cargo-crev is built on the web of trust, so when you trust person, you now implicitly trust all the other people they trust. I think that's fine for casual projects, but I think we're a lot more paranoid than that! I imagine we would trust the audits done by Mozilla/Firefox since if we don't trust them we're already pwned, but not necessarily every person who someone who works on Firefox trusts.

And ultimately cargo-vet seems conceptually simpler, there's no cryptography involved or keys or IDs, it just relies on git repos (so HTTPS).

[legoktm]

I tried out cargo vet today, it seems to work pretty nicely. The main "issue" I ran into was that we are deploying to a very specific platform ("target" in Rust lingo), Linux x86_64. There are a bunch of Windows/WASM/Redox dependencies in the vet list that we don't actually use that I filtered out manually based on mozilla/cargo-vet#63 (comment). That ticket has some suggestions on how upstream can implement some form of target limiting.

[legoktm]

Thinking closely about the Python diff review workflow, there are two steps missing:

• We don't verify that the version we review matches checksum of what is included in Cargo.lock. This probably needs to be fixed upstream.
• There's no opportunity to PGP sign the review. If we consider this to be a requirement, I would suggest we just mandate GPG-signing of commits that add new audits.

[legoktm]

I think we're mostly set on going forward with cargo vet, but FWIW Google has also adopted it: https://opensource.googleblog.com/2023/05/open-sourcing-our-rust-crate-audits.html