You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cargo-vet allows project's to evaluate audit trails for dependencies, something that is very interesting for cargo-deny to support, either as an additional check, or perhaps as an addition to the bans check. This functionality could be useful for either implementing or complementing features such as #19
See mozilla/cargo-vet#82 for the issue to actually make cargo-vet usable as a library.
The text was updated successfully, but these errors were encountered:
I was initially thinking that we can just run cargo-vet manually in CI instead of having it integrated in cargo-deny, as it would be standalone and wouldn't use any of the other cargo-deny features and has its own configurations instead of deny.toml.
Though one really good benefit of having it integrated here would be that it would streamline CI workflows, we already run cargo-deny in all of our private and public repositories and both through CI image installs of cargo-deny and of through our Github Action. So if we had a cargo deny check audits that does run an embedded library version of cargo-vet that only can validate that crates are vetted/audited (not update audits or user workflows) that would be easier for CI.
So I'm all in favor of this! And think we we should try and do it this way, if possible, rather than installing and adding cargo-vet manually to our CI steps. Though depends on when we can have the library version, think we want to enable cargo-vet CI checks within a couple of months max.
Developers would still have to have cargo-vet installed locally though to be able to interact with it to add new audits, do diffs and such, but think that is fine. And later on hopefully we'll get an interactive GitHub workflow for that to diff and add audits in a PR instead:
cargo-vet
allows project's to evaluate audit trails for dependencies, something that is very interesting for cargo-deny to support, either as an additional check, or perhaps as an addition to thebans
check. This functionality could be useful for either implementing or complementing features such as #19See mozilla/cargo-vet#82 for the issue to actually make cargo-vet usable as a library.
The text was updated successfully, but these errors were encountered: