❌ cargo-deny

Build Status Latest version Docs SPDX Version Contributor Covenant Embark

One of the key selling points of Rust is the ever growing and improving ecosystem of crates available that can be easily added to your project incredibly easily via cargo. This is great! However, the larger the project is and the more dependencies you have, the harder it is to keep track of certain things, especially as a project evolves over time, which is what cargo-deny tries to help you with.

Install

cargo install cargo-deny

tl;dr

Licenses - cargo deny check licenses

One important aspect that one must always keep in mind when using code from other people is what the licensing of that code is and whether it fits the requirements of your project. Luckily, most of the crates in the Rust ecosystem tend to follow the example set forth by Rust itself, namely dual-license MIT OR Apache-2.0, but of course, that is not always the case.

So cargo-deny allows you to ensure that all of your dependencies have license requirements that align with your configuration.

Precedence

Currently, the precedence for determining whether a particular license is accepted or rejected is as follows:

  1. A license specified in the deny list is always rejected.
  2. A license specified in the allow list is always accepted.
  3. If the license is considered copyleft, the [license.copyleft] configuration determines its status
  4. If the license is OSI Approved or FSF Free/Libre, the [license.allow-osi-fsf-free] configuration determines its status
  5. If the license does not match any of the above criteria, it is implicitly rejected.

The [licenses] section

Contains all of the configuration for cargo deny check license.

The unlicensed field (optional)

Determines what happens when a crate has not explicitly specified its license terms, and no license information could be easily detected via LICENSE* files in the crate's source.

The allow and deny fields (optional)

The licenses that should be allowed or denied. The license must be a valid SPDX v2.1 identifier, which must either be in version 3.7 of the SPDX License List, with an optional exception specified by WITH <exception-id>, or else a user defined license reference denoted by LicenseRef-<idstring> for a license not on the SPDX License List.

NOTE: The same license cannot appear in both the allow and deny lists.

GNU licenses

The GNU licenses are, of course, different from all the other licenses in the SPDX list which makes them annoying to deal with. When supplying one of the above licenses, to either allow or deny, you must not use the suffixes -only or -or-later, as they can only be used by the license holder themselves to decide under which terms to license their code.

So, for example, if you we wanted to disallow GPL-2.0 licenses, but allow GPL-3.0 licenses, we could use the following configuration.

toml [licenses] allow = [ "GPL-3.0" ] deny = [ "GPL-2.0" ]

The exceptions field (optional)

The license configuration generally applies the entire crate graph, but this means that, allowing a specific license applies to all possible crates, even if only 1 crate actually uses that license. The exceptions field is meant to allow licenses only for particular crates, so as to make a clear distinction between licenses are fine with everywhere, versus ones which you want to be more selective about, and not have implicitly allowed in the future.

The name field

The name of the crate that you are adding an exception for

The version field (optional)

An optional version constraint specifying the range of crate versions you are excepting. Defaults to all versions (*).

The allow field

This is the exact same as the general allow field.

toml [licenses] allow = [ "Apache-2.0", "MIT", ] exceptions = [ # This is the only crate that cannot be licensed with either Apache-2.0 # or MIT, so we just add an exception for it, meaning we'll get a warning # if we add another crate that also requires this license { name = "cloudabi", allow = ["BSD-2-Clause"] }, ]

The copyleft field (optional)

Determines what happens when a license that is considered copyleft is encountered.

The allow-osi-fsf-free field (optional)

Determines what happens when licenses aren't explicitly allowed or denied, but are marked as OSI Approved or FSF Free/Libre in version 3.6 of the SPDX License List.

The confidence-threshold field (optional)

cargo-deny uses askalono to determine the license of a license file, the confidence threshold value determines if askalono's determination meets your minimum requirements. The higher the value, the more closely the license text must be to the canonical license text of a valid SPDX license file.

0.0 - 1.0 (default 0.8)

The clarify field (optional)

In some exceptional cases, the crate does not have easily machine readable license information, and would by default be considered "unlicensed" by cargo-deny. As a (hopefully) temporary patch for using the crate, you can specify a clarification for a crate where you can specify the license expression based on your understanding of the requirements as described by the license holder.

The name field

The name of the crate that you are clarifying

The version field (optional)

An optional version constraint specifying the range of crate versions you are clarifying. Defaults to all versions (*).

The expression field

The SPDX license expression you are specifying as the license requirements for the crate in question.

The license-files field

Contains one or more files that will be checked to ensure the license expression still applies to a version of the crate. Each file is a path to the file relative to the crate route, and a hash of the contents to detect changes between versions. This hash is printed out when license files cannot have their license determined with high confidence.

Example config

```toml [licenses] unlicensed = "deny" allow-osi-fsf-free = "either" copyleft = "ignore" confidence-threshold = 0.92 deny = [ "GPL-3.0-or-later", ] allow = [ "Apache-2.0", "Apache-2.0 WITH LLVM-exception", "BSD-3-Clause", "MIT", "Zlib", ]

ring has a rather complicated license file, and unfortunately does not

provide an SPDX expression in the license toml

[[licenses.clarify]] name = "ring"

SPDX considers OpenSSL to encompass both the OpenSSL and SSLeay licenses

https://spdx.org/licenses/OpenSSL.html

ISC - Both BoringSSL and ring use this for their new files

MIT - "Files in third_party/ have their own licenses, as described therein. The MIT

license, for thirdparty/fiat, which, unlike other thirdparty directories, is

compiled into non-test libraries, is included below."

OpenSSL - Obviously

expression = "ISC AND MIT AND OpenSSL" license-files = [ { path = "LICENSE", hash = 0xbd0eed23 }, ] ```

Crate bans - cargo deny check bans

Use Case - Keeping certain crates out of your dependency graph

Sometimes, certain crates just don't fit in your project, so you have to remove them. However, nothing really stops them from sneaking back in due to small changes, like updating a crate to a new version that happens to add it as a dependency, or an existing dependency just changing what crates are included in the default feature set.

For example, we previously depended on OpenSSL as it is the "default" for many crates that deal with HTTP traffic. This was extremely annoying as it required us to have OpenSSL development libraries installed on Windows, for both individuals and CI. We moved all of our dependencies to use the much more streamlined native-tls and ring crates instead, and now we can make sure that OpenSSL doesn't return from the grave by being pulled in as a default feature of some future HTTP crate we might use.

Use Case - Get a handle on duplicate versions

One thing that is part of the tradeoff of being able to use so many crates, is that they all won't necessarily agree on what versions of a dependency they want to use, and cargo and rust will happily chug along compiling all of them. This is great when just trying out a new dependency as quickly as possible, but it does come with some long term costs. Crate fetch times (and disk space) are increased, but in particular, compile times, and ultimately your binary sizes, also increase. If you are made aware that you depend on multiple versions of the same crate, you at least have an opportunity to decide how you want to handle them.

The [bans] section

Contains all of the configuration for cargo deny check ban

The multiple-versions field (optional)

Determines what happens when multiple versions of the same crate are encountered.

The highlight field (optional)

When multiple versions of the same crate are encountered and the multiple-versions is set to warn or deny, using the -g <dir> option will print out a dotgraph of each of the versions and how they were included into the graph. This field determines how the graph is colored to help you quickly spot good candidates for removal or updating.

Imgur

Crate specifier

The allow, deny, skip, and skip-tree fields all use a crate identifier to specify what crate(s) they want to match against.

{ name = "some-crate-name-here", version = "<= 0.7.0" }

The name field

The name of the crate.

The version field (optional)

An optional version constraint specifying the range of crate versions that will match. Defaults to all versions (*).

The allow and deny fields (optional)

As with licenses, these determine which specificy crates and version ranges are actually allowed or denied.

The skip field (optional)

When denying duplicate versions, it sometimes takes time to update versions in transitive dependencies, or big changes in core often used crates such as winapi and others to ripple through the rest of the ecosystem. In such cases, it can be ok to remove certain versions from consideration so that they won't trigger failures due to multiple versions, and can eventually be removed once all crates have update to the later version(s).

Note entries in the skip field that never match a crate in your graph will have a warning printed that they never matched, allowing you to clean up your configuration as your crate graph changes over time.

The skip-tree field (optional)

When dealing with duplicate versions, it's often the case that a particular crate acts as a nexus point for a cascade effect, by either using bleeding edge versions of certain crates while in alpha or beta, or on the opposite end, a crate is using severely outdated dependencies while much of the rest of the ecosystem has moved to more recent versions. In both cases, it can be quite tedious to explicitly skip each transitive dependency pulled in by that crate that clashes with your other dependencies, which is where skip-tree comes in.

skip-tree entries are similar to skip in that they are used to specify a crate name and version range that will be skipped, but they also have an additional depth field that can be used to specify the depth from that root crate that will also be ignored when checking for duplicates. In that sense, a depth of 0 would be functionally the same as specifying the same crate name and version constraint in the skip list instead.

Note that by default, the depth is infinite.

Example Config

```toml [bans] multiple-versions = "deny" deny = [ # You can never be too sure { name = "openssl-sys" }, ] skip = [ # askalono 0.3.0 uses an ancient regex version which pulls # in other duplicates { name = "regex", version = "=0.2.11" }, { name = "regex-syntax", version = "=0.5.6" }, { name = "aho-corasick", version = "=0.6.10" },

# some macro crates use the pre 1.0 syn dependencies
{ name = "syn", version = "<=0.15" },
{ name = "proc-macro2", version = "<=0.4" },
{ name = "quote", version = "<=0.6" },
{ name = "unicode-xid", version = "=0.1" },

] skip-tree = [ # tonic is in alpha right now, and pulls in many alpha versions of tokio/tower # crates, so ignore all of them for now until things stabilize { name = "tonic", version = "0.1.0-alpha.4" }, # ignore older rand as many crates still use it instead of the newer 0.7+ version { name = "rand", version = "=0.6.5" }, ] ```

Crate advisories - cargo deny check advisories

Use Case - Detecting security vulnerabilities

Security vulnerabilities are generally considered "not great" by most people, luckily rust has a great advisory database which cargo-deny can use to check that you don't have any crates with (known) security vulnerabilities.

Use Case - Detecting unmaintained crates

The advisory database also contains advisories for unmaintained crates which in most cases users will want to avoid in favor of more active crates.

The [advisories] section

Contains all of the configuration for cargo deny check advisories

The db-url field (optional)

URL to the advisory database's git repo

Default: https://github.com/RustSec/advisory-db

The db-path field (optional)

Path to the local copy of advisory database's git repo

Default: ~/.cargo/advisory-db

The vulnerability field (optional)

Determines what happens when a crate with a security vulnerability is encountered.

The unmaintained field (optional)

Determines what happens when a crate with an unmaintained advisory is encountered.

The notice field (optional)

Determines what happens when a crate with a notice advisory is encountered.

NOTE: As of 2019-12-17 there are no notice advisories in https://github.com/RustSec/advisory-db

The ignore field (optional)

Every advisory in the advisory database contains a unique identifier, eg. RUSTSEC-2019-0001, putting an identifier in this array will cause the advisory to be treated as a note, rather than a warning or error.

The severity-threshold field (optional)

The threshold for security vulnerabilities to be turned into notes instead of of warnings or errors, depending upon its CVSS score. So having a high threshold means some vulnerabilities might not fail the check, but having a log level >= info will mean that a note will be printed instead of a warning or error depending on [advisories.vulnerability].

CI Usage

We now have a Github Action for running cargo-deny on your Github repositories, check it out here.

If you don't want to, or can't, use the action, you can look at the self check job for this repository, which just checks cargo-deny itself using the deny.toml config for how you run it in on your own code.

Also note, that while you can install cargo-deny via the normal cargo install process, we prebuild binaries for Linux, MacOS, and Windows for every release which you can use something like this.

```sh

!/bin/bash

set -eu

mkdir /tmp/cargo-deny

curl -L -o /tmp/cargo-deny/archive.tar.gz https://github.com/EmbarkStudios/cargo-deny/releases/download/0.5.1/cargo-deny-0.5.1-x86_64-unknown-linux-musl.tar.gz

tar -xzvf /tmp/cargo-deny/archive.tar.gz --strip-components=1 -C /tmp/cargo-deny

/tmp/cargo-deny/cargo-deny --context . -L debug check bans licenses advisories ```

List - cargo deny list

Similarly to cargo-license, print out the licenses and crates that use them.

Imgur

Imgur

Imgur

Imgur

Contributing

We welcome community contributions to this project.

Please read our Contributor Guide for more information on how to get started.

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.