Vetting the cargo

> 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.

In real work terms, it means that you'll just import the audits done by someone else. This is why the import function exists in the first place. It's not a transitive trust model, it's a delegate trust model. In the end, there is no difference as the author of all-padding will tell you that his project and its dependencies are trusted by project foo, bar and baz and will points you to the audit tile in order to ease the integration of his own module in your project. And most people will do it, because it's easier this way. Or the author will find a way to add himself in a global, trusted repository. Or he will tell you to trust another registry.

Developpers tend to pick easy solutions (otherwise the npm development model would not even exist), and as a module author, giving them clear, easy instructions to follow in order to avoid being turned down by this pesky CI tests is going to be valued.

You might argue that this is dumb and it should not exist, but, hey, large security appliances are often presenting stupid security holes (like this one: https://twitter.com/AnnaViolet20/status/15235646321405091... ; take some time to think about how is it even possible for a global leader in security to spawn a REST API which runs as root and does not even check for any credential apart from the presence of a specific header which is widely documented. The answer is along the line of "well... Oh! look at this wonderful sky!").

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

I would argue that it's definitevely worse, as I now have a tool that tells me it's definitely ok to do that.

> 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.

I would not assume that this feature will only be used by small developpers. Large developpers shops are also likely to use it in order to make sure they hit their delivery time - because now that the tool exist, support for the tool will be added in CI systems, and suddenly, as a developper, you'll have to accept audits results.

> 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.

Well, this is one of the reason for the development of cargo vet: you cannot assume the users (even large companies) will audit the code because this is not practical. So the level of non-diligence is already here. I would even say that refusing the audit would lead you directly to square zero.

I would also add that there is no actual reason to not trust the author of all-padding. On what ground should I do that? (and I'm OK that in real life, I will have a harder time to trust him than to trust Mozilla, so that's more of a devil's attorney question).

Don't misunderstand my position: I understand that having a tool to help code audit is a good thing. But given the choosen development model (as the developpers of cargo-vet calls it: "low-friction reuse of third-party components") this is just bandage on a wooden leg. The problem is that the development model in itself is dangerous. This has been proven times and times again. While it might reduce risks (and I'm not even sure of that) no amount of tooling might change that.