Cargo-crev's writ seems to be much more expansive and nebulous than security: https://github.com/crev-dev/cargo-crev/wiki/Howto:-Create-Review-Proofs https://g

Cargo-crev's writ seems to be much more expansive and nebulous than security: https://github.com/crev-dev/cargo-crev/wiki/Howto:-Create-Review-Proofs https://github.com/crev-dev/cargo-crev/wiki/Howto:-Create-Re... > While it's still open for debate, the current opinion is that additional fields are not useful for the downstream users. Instead they just complicate their life, putting the burden of the decision from the reviewer onto them. At the end, a downstream user of a review just wants to know: "is it OK to use this package or not?". Your role as a reviewer is to provide that judgment. That irks me. I don't care about popularity contests, I only care whether a crate is malicious or not. If it has security vulnerabilities, I can deal. But if downloading and running a proc macro crate build runs gives an attacker remote code execution and they install a keylogger on my dev box, that's altogether different.