Vetting the cargo

> I understand that, but it's still not a good solution. Let me introduce all-padding, a crate that depends on both right-padding (developped by an associate of mine, yet you don't know that) and left-padding. Both dependencies are innocuous at the time you need them, so I audited them and told the world they are safe to deploy. Since padding function are "difficult" and your time is better spent implementing the REST API of the coffee machine, you add all-padding as a dependency. You audit my code, and it's ok, so all-padding is audited as safe to deploy as well.

And then cargo-vet tells you that you also need to audit left-padding and right-padding, because it intentionally does not have a transitive trust model.

> And since you've worked with all-padding for ages, you trust me, so you don't reevaluate right-padding by yourself : I just told you it was ok.

And that was a process mistake that no tool can prevent you from making.

While cargo-vet allows you to import audits from other projects, I have the impression that's intended for use cases like "I'm a small developer and don't want to vet all my dependencies, so I'm going to import the audits of a large project that has security reviewers I trust, such as Mozilla". Which will leave you better off than the audits you might otherwise have done yourself. If, instead of delegating your trust to developers of a large well-known project, you delegate your trust to the author of all-padding, you will get a corresponding level of non-diligence.