Open divergentdave opened 1 year ago
This seems like a bug. We'll look into it.
This is caused by the way that cargo-vet
thinks about roots and crate graphs. Rather than considering every crate in your workspace as an individual root, crates are considered roots if they have no reverse-dependencies. This prevents the default per-root policy from applying to any crates which could instead have requirements enforced by dependency edges.
This ends up impacting your case, as the test crate depends on your primary crate, so the primary crate is not considered a root. This leads to the primary crate's requirements to be inferred from the test crate's through the dependency edge, which adds a safe-to-run
requirement to it.
The decision was made originally not not have the policy apply to each workspace member individually for use-cases where the workspace contains dependency trees used to implement internal tooling. For example, in Gecko we have a geckodriver
crate which depends on other internal crates such as marionette
and mozversion
. If every workspace crate was considered a root, you'd need to specify a policy for each crate in the workspace to reduce the geckodriver
subtree to safe-to-run
, whereas with this model, it happens by inheritance.
I can't think of a way off the top of my head to detect and handle both this case and the geckodriver
case automatically, as they look the same in the dependency graph. The easiest approach right now is to explicitly specify the safe-to-deploy
policy for each crate which is depended on by a safe-to-run
crate.
We might be able to add an option to toggle the behaviour for what to treat as a root for evaluation, or perhaps add some option to the policy making in-workspace dependencies be treated as roots, if this turns out to be a big issue.
I experimented with setting up
cargo vet
on a couple repositories that have the following setup: some crates which we publish, and some other testing/development-only crates in the same workspace that depend on the published crates. If I set the criteria on testing crates tosafe-to-run
in the configuration file, then when I runcargo vet suggest
, I only get suggestions forsafe-to-run
audits, and no suggestions forsafe-to-deploy
audits. If I explicitly set the criteria for all workspace crates in the configuration file, thencargo vet suggest
gives me separate nonempty lists of suggestedsafe-to-run
andsafe-to-deploy
audits, which is the behavior I want. It sounds like, via dependency edges, the policy changes on one workspace crate are affecting another workspace crate, and overriding the expected default behavior ofsafe-to-deploy
for all workspace crates.Here's a simplified example:
No policy configurations, OK:
After setting
policy.crate-b.criteria = "safe-to-run"
, I get this unexpected behavior:Lastly, I set both
policy.crate-a.criteria = "safe-to-deploy"
andpolicy.crate-b.criteria = "safe-to-run"
, and get the behavior I want:I installed
cargo-vet
from commit 61d140dabe996938cf10900b73e93b705270cc9f.