New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo-vet: Exclude fuzzing-only dependencies #8488
Conversation
5502f79
to
cc6da3b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a reasonable change to make yeah, we already don't vet these dependencies much and reducing our backlog seems reasonable to me
Makes sense to me too. |
Same for me, yeah. It'd be good to have this mentioned somewhere in documentation people running fuzzing would be likely to see |
Good point. I'll add some text to Also, do we have text somewhere that I should update describing our cargo-vet policy? |
We can't meaningfully audit the other WebAssembly implementations that we use for differential fuzzing, such as wasmi and especially v8. Let's acknowledge that the effort to do so is not practical for us, and focus our vetting efforts on crates that developers and users are more likely to build. This reduces our estimated audit backlog by over three million lines, according to `cargo vet suggest`. Note that our crates which depend on those engines, such as wasmtime-fuzzing, are not published to crates.io, so if we fall victim to a supply chain attack against dependencies of these crates, the folks who might be impacted are limited. Although there is value in also auditing code that might be run by people who clone our git repository, in this case I propose that anyone who is concerned about the risks of supply chain attacks against their development systems should be running fuzzers inside a sandbox. After all, it's a fuzzer: it's specifically designed to try to do anything.
cc6da3b
to
c1ba015
Compare
I've pushed some new text for I considered adding text to I also considered adding text to Finally, I considered trying to make suggestions about sandboxes people could try, and got as far as verifying that |
Subscribe to Label Actioncc @fitzgen
This issue or pull request has been labeled: "fuzzing"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
I think this is pretty reasonable so I'm gonna go ahead and flag for merge given the consensus here. @tschneidereit if you've got further thoughts though on the docs though we can always have follow-ups too |
Thank you for doing this, @jameysharp! I agree that these doc changes are good, and also with your reasoning for not making other doc changes :) |
We can't meaningfully audit the other WebAssembly implementations that we use for differential fuzzing, such as wasmi and especially v8. Let's acknowledge that the effort to do so is not practical for us, and focus our vetting efforts on crates that developers and users are more likely to build.
This reduces our estimated audit backlog by over three million lines, according to
cargo vet suggest
.Note that our crates which depend on those engines, such as wasmtime-fuzzing, are not published to crates.io, so if we fall victim to a supply chain attack against dependencies of these crates, the folks who might be impacted are limited.
Although there is value in also auditing code that might be run by people who clone our git repository, in this case I propose that anyone who is concerned about the risks of supply chain attacks against their development systems should be running fuzzers inside a sandbox. After all, it's a fuzzer: it's specifically designed to try to do anything.
I'd like to especially seek comment from folks who've expressed interest in our use of cargo-vet, like @alexcrichton, @bholley, @cfallin, and @tschneidereit. I'm open to being persuaded that we shouldn't make this change, but I can't currently see that we get any value from auditing these particular dependencies.