Deprecate several fields #606
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
Jake-Shadle
added a commit
that referenced
this pull request
Feb 23, 2024
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](https://embarkstudios.github.io/cargo-deny/checks/licenses/cfg.html#the-clarify-field-optional) 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.
nagisa
added a commit
to nagisa/nearcore
that referenced
this pull request
Jun 10, 2024
EmbarkStudios/cargo-deny#606 The new version also noted that a number of ignores are no longer necessary, so I cleaned them up too (while spot-checking some of them)
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Jun 11, 2024
EmbarkStudios/cargo-deny#606 The new version also noted that a number of ignores are no longer necessary, so I cleaned them up too (while spot-checking some of them)
V0ldek
added a commit
to rsonquery/rsonpath
that referenced
this pull request
Jun 28, 2024
V0ldek
added a commit
to rsonquery/rsonpath
that referenced
this pull request
Jun 28, 2024
V0ldek
added a commit
to rsonquery/rsonpath
that referenced
this pull request
Jun 29, 2024
* chore(ci): fix a number of new nightly warnings * deps: updated a number of dependencies bump clap from 4.5.4 to 4.5.7 bump log from 0.4.21 to 0.4.22 bump thiserror from 1.0.58 to 1.0.61 * chore(ci): update deny.toml according to cargo-deny breaking changes See EmbarkStudios/cargo-deny#606. * chore(test): fix tests in quotes that were erroneously disabled * chore(doc): fix a bunch of documentation whitespace lints
|
To be clear, are fields such as |
|
Yes #611 |
jonhoo
added a commit
to jonhoo/flurry
that referenced
this pull request
Aug 18, 2024
flo-at
added a commit
to flo-at/minmon
that referenced
this pull request
Aug 25, 2024
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR deprecates several fields which will be removed in a future update. I'll explain in detail why below, but the TLDR is that cargo-deny surfaces several configuration options that were added because we could, but not necessarily because they are useful in practice.
Licenses
denyThis field was only added for consistency with
[bans]but makes no sense for[licenses], if a license you don't explicitly allow is used it is implicitly denied.copyleftThere is no reason to treat these differently from any other license, if it's not explicitly allowed it should be denied, and it just adds confusion due to the terrible default.
See: #602
See: #354
allow-osi-fsf-freeSimilarly to copyleft, this field just makes no sense and was only added because the SPDX metadata allowed us to query this information.
defaultThis was added so that users could just ignore/warn all their dependencies not following the set of allowed licenses, but just isn't much value. Even in large projects with literally hundreds of external dependencies the set of licenses that need to be allowed are relatively small compared to the total set of licenses in SPDX due to the Rust ecosystem generally using only a handful of licenses, with rare exceptions.
unlicensedCrates that don't specify a license via
[package.license/license-file]or have a license file in their package source are incredibly rare, and there is already a mechanism to provide/override license information for those rare crates.Advisories
Blanket
vulnerabilityunmaintainedunsoundnoticeThere's no need to blanket handle any of these specific advisory types, there just aren't enough advisories (currently, this could change in the future) that a typical workspace will encounter that they can't be handled explicitly via
ignore.See: #449
severity-thresholdThis optional field is available in rustsec advisories, but provides no real value as it's just flavor on top of a reported vulnerability, but doesn't fundamentally change that it is a vulnerability, and can either be ignored or better yet, updated to a version without the vulnerability.