Add version = 2

[Jake-Shadle]

This is a follow up to #606 that actually provides a way to remove the deprecated fields and opt in to the new behavior until the fields are removed and the new behavior becomes the only behavior.

Basically, version = 2 can be added to the [advisories] and [licenses], which opts in to the new behavior, and means any of the deprecated keys no longer impact the results of the checks.

The new behavior is as follows:

[advisories]

• vulnerability - deny
• unmaintained - deny, old default = warn
• unsound - deny, old default = warn
• notice - deny, old default = warn
• severity-threshold - CVSS severity no longer considered

Resolves: #449

[licenses]

unlicensed

New default of deny, old default was warn.

If a crate is unlicensed, a clarification can be used to assign a license based on one or more source files in the package

allow-osi-fsf-free

Old default was both, the new default is neither, ie, it doesn't matter if the license is osi and/or fsf free, only if it is in the allow (or exception) list.

copyleft

Old default was warn, the new default is deny, it only matters if the license is allowed in the allow or exception list.

Resolves: #602 Resolves: #354

default

Provided the default for a license not otherwise listed, now all licenses are deny unless explicitly in the allow or exception list.

deny

This list served no purpose, if the license is not in the allow or exception list, it is denied.

[ameknite]

I don't like that to fix bugs, features are being removed.

Maybe this could help someone:

To check if a license is osi or fsf-free, check the SPDX License List: https://spdx.org/licenses/

To check if a license is copyleft you can search for the "same license" column here: https://choosealicense.com/appendix/

[Jake-Shadle]

I'll add this metadata to the output when a license has not been explicitly allowed, but the features that are being removed are just not useful and confusing to users.

[LucasFA]

unmaintained - deny, old default = warn

Cargo deny warns me that the configuration field will be removed. If I understand correctly that it will have no option to only warn when encountering unmaintained crates, it seems a bit aggresive, to me.

For context, I am collaborating on a project that depends on librespot, which while in development, has not seen a release in 2 years and thus depends on several unmaintained crates.

[Jake-Shadle]

https://embarkstudios.github.io/cargo-deny/checks/advisories/cfg.html#the-ignore-field-optional

[tisonkun]

@Jake-Shadle what if throwing an error when version = 2? Eat deprecated keys doesn't sound a good idea. When users (like me) wants to migrate to version = 2, I'd prefer to ensure that all my setup is correct and no redundant.

[davidv1992]

I am running into errors that refer to this for migration instructions, but am unclear on the migration path from the licenses keys. What should these be replaced with?

[Jake-Shadle]

All licenses are implicitly denied unless added to accept or exceptions

[aidanhs]

This change effectively blocks contributors to my project if an advisory has been issued since the last CI build. I'm fine with this for vulnerabilities as it gives me a heads up to fix it myself, but I don't really care if something has become unmaintained - I had previously set it to warn (as a nudge when I run CI checks locally).

Looks like I need to skip all advisory checks in CI now and have a separate checking script for local flow...which is a bit disappointing.

[kornelski]

Could cargo deny do the migration automatically? (preserving old meaning wherever possible)

I have hundreds of internal crates to update, and I'd rather not do that in a manual error-prone way.

[torokati44]

(I hate to say this, but this sounds like a perfect task to automate with an LLM. Show it an example before-after, and it should be able to rewrite the rest accordingly. Yes, still error-prone of course, but it's easier to just check than to do by hand. I think.)