cargo-deny is a cargo plugin for linting your dependencies

See the cargo-deny-action

❌ cargo-deny

Cargo plugin for linting your dependencies

See the book 📕 for in-depth documentation.

To run on CI as a GitHub Action, see cargo-deny-action.

Please Note: This is a tool that we use (and like!) and it makes sense to us to release it as open source. However, we can’t take any responsibility for your use of the tool, if it will function correctly or fulfil your needs. No functionality in - or information provided by - cargo-deny constitutes legal advice.

Quickstart

Usage

Install cargo-deny

If you want to use cargo-deny without having cargo installed, build cargo-deny with the standalone feature. This can be useful in Docker Images.

Initialize your project

Check your crates

Licenses

The licenses check is used to verify that every crate you use has license terms you find acceptable.

Bans

The bans check is used to deny (or allow) specific crates, as well as detect and handle multiple versions of the same crate.

Advisories

The advisories check is used to detect issues for crates by looking in an advisory database.

Sources

The sources check ensures crates only come from sources you trust.

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

  • Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
  • MIT license (LICENSE-MIT or <#404>)

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.

Issues

Collection of the latest Issues

danielhaap83

danielhaap83

bug
3

Describe the bug cargo deny fetch fails with errors configuring my custom advisory-db using https and gits credential.helper = store.

A simple git clone https://github.com/xxx/advisory-db is working fine.

To Reproduce Steps to reproduce the behavior:

  1. configure a private repository (https auth) of your choice in deny.toml advisories.db-urls
  2. set git credential helper to store git config --global credential.helper store
  3. clone the configured repository via git to create the store git clone https://github.com/xxx/private-repo
  • enter username and password. I used my private access token as password
  1. call cargo deny to fetch the configured repository cargo deny fetch
  2. See error

This is just example to reproduce. Of course it is not functional to use any repository as advisory-db.

Expected behavior cargo-deny is fetching the private repository

Device:

  • Ubuntu 20.04.4 LTS
  • git version 2.25.1
  • cargo-deny 0.11.0
hrydgard

hrydgard

enhancement
0

Sometimes, it might be interesting to use libraries with release-incompatible licenses in [dev-dependencies]. One example would be dssim, which is licensed under AGPL, and can be useful for comparing graphical output to a reference image while tolerating minor visually-invisible differences. In this case, its license doesn't need to be considered for the final binary release since neither the code nor any of its output will be included in it.

In deny.toml, the interface for this could be to simply have an additional allow-dev section. Like below:

dev-allow would implicitly include everything from allow, since I can't really imagine a case where a library would not be OK to use for local tests, but OK in a final binary.

RyanMeulenkamp

RyanMeulenkamp

enhancement
0

Is your feature request related to a problem? Please describe.

For our CI we would like to split checking the dependencies over two periods:

  • Changed dependencies before merging the PR
  • Existing dependencies at an interval (e.g. daily)

That way we don't block every open PR when a security issue pops up, but we still prevent a PR from merging if it introduces a bad dependency.

I can see a few different approaches to this problem. I'm totally open to suggestions here. I can´t imagine this CI strategy is unique to us so maybe someone has already implemented something like this.

Describe the solution you'd like The nicest solution from the user's perspective would be to simply have an argument, say --changed-since, to which you can pass a git reference, and it only takes those dependencies into account.

Describe alternatives you've considered Two other possible solutions I can see:

  • (this might be possible already): allow passing a list to the CLI of what dependencies to consider. Takes some additional interpretation work from the user's side to list all the dependencies, from the Cargo.toml's that were changed since a certain point in time.
  • Add this feature to the Github Action.
Jake-Shadle

Jake-Shadle

bug
0

As reported in #380, newer versions of libgit2 segfault with the current 0.13 version of git2 that is used by cargo-deny, but this is fixed (for now... https://github.com/rust-lang/git2-rs/pull/817) by bumping to 0.14. However, libgit2-sys is an FFI wrapper with links and thus can only have 1 version, and we rely on several other dependencies that are still on the old 0.13 that we have to wait on.

repi

repi

enhancement
0

We had an exemption of a crate deny rule for another crate that still needed it, which we used the wrappers field for (a bit hacky), like this:

but a later version of those tract-* crates had then finally removed the dependency on inventory and it was no longer reference in our Cargo.lock but we didn't know. Would be nice if cargo-deny would have logged out a warning about an unused wrappers field here for the crates so one can get a heads up and remove it.

Jake-Shadle

Jake-Shadle

enhancement
0

I added workarounds to cargo-about since there are a lot of crates, even widely used ones, that make machine reading of the license impossible or actually don't package the license text at all, even though it is a requirement of many licenses to do so. Having workarounds that users can easily apply rather than providing clarifications would be a nice quality of life improvement, in addition to #121. Eg. #389.

hanabi1224

hanabi1224

enhancement
0

Describe the bug cargo works with the combination of below ~/.gitconfig and ~/.cargo/config , but cargo deny check advisories fails with errors.

~/.gitconfig

~/.cargo/config

Error:

To Reproduce Steps to reproduce the behavior:

  1. create ~/.gitconfig and ~/.cargo/config with the content above
  2. run setup ssh keys for git cli
  3. run cargo update against any crate, it should work fine
  4. run cargo deny check advisories, it fails with error above

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Device:

  • OS: windows 11 / wsl2 Ubuntu 20.04
  • Browser [e.g. chrome, safari]
  • Version [e.g. 22]

Additional context Add any other context about the problem here.

briansmith

briansmith

question
4

In various CI/CD pipelines I am running both cargo-audit and cargo-deny. Recently I had to override a "unmaintained crate" warning and I was surprised to find I had to change both the cargo-deny and cargo-audit configuration. Then, the more I looked into things, the less I felt I understood what cargo-deny does that cargo-audit does, and vice-versa.

Also I want to work on some non-trivial enhancements to one tool or the other tool, but it isn't clear which tool I should add the enhancements to. Right now it looks like I'd need to propose the enhancements to both, and work on both in parallel.

I am subscribed to the now-closed issue #194 which was about, IIUC, merging cargo-audit and cargo-deny into one thing, but then something happened that I don't understand that caused that effort to stall out. It isn't clear to me to what extent the issues are technical vs. organizational.

My understanding from reading #194 is that cargo-audit does advisory checks in a way that reduces the number of advisories that one needs to worry about, relative to what cargo-deny does. Modulo that, is there any reason to use cargo-audit vs. cargo-deny now?

Conversely, if one is interested in the better advisory support in cargo-audit, then how would you recommend one configure cargo-deny so that it doesn't do any checks that are 100% redundant with what cargo-audit does?

djc

djc

enhancement
2

Is your feature request related to a problem? Please describe.

When reviewing duplicate dependencies as reported by cargo deny, I'd like it if there was a consistent ordering. For example, I currently get this output:

Note that strsim v0.10.0 is shown before strsim v0.8.0 while tokio-rustls v0.22.0 is shown before tokio-rustls v0.23.1. I'm not sure that it matters much what the order is, but it would be nicer to process these reports if the order was consistent.

kate-shine

kate-shine

enhancement
1

Is your feature request related to a problem? Please describe. We are using a shared deny.toml for all repositories in our CI (It makes a maintenance of config for repositories simpler). Therefore, we are getting plenty of L005 (license exception was not encountered) and S006 (allowed organization was not encountered) code warnings, which are of no interest to us.

Describe the solution you'd like The central config can have a list of ignored Diagnostic codes that will be skipped.

Describe alternatives you've considered Specific options for certain checks, like unused-allowed-license already does. But I still think that having one central space to hide some codes from the output entirely would make for a more flexible setting.

jplatte

jplatte

bug
16

Describe the bug

It's a segmentation fault! The program crashes after printing a warning about being unable to find a config path. I wanted to just have it use the default config in a project where I haven't set one up yet.

To Reproduce

Expected behavior

Successfully

Additional context

This is cargo-deny 0.10.3 installed to /usr/bin through the arch linux package. Maybe it fails to mmap the default config file or something like that? Here's the package build script, it's really minimal: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cargo-deny

Jake-Shadle

Jake-Shadle

enhancement
0

When gathering metadata, cargo will first need to fetch crates if the manifest/lockfile have changed, but during this time we don't report progress back to the user at all unlike a normal cargo fetch/build/etc so it can look hung if the fetch takes a significant amount of time (eg large git dependencies), so we should either pipe the progress report for the fetch or wrap it on our own so that the user knows that it is actually doing work.

Jake-Shadle

Jake-Shadle

question
2

Follow up from the discussion started in #341.

I've now added support for --frozen, --locked, and --offline (which also disables advisory database fetching). I plan on exposing these flags in the Github Action as well.

As far as the defaults are concerned, I think it makes sense to separate the 2 main use cases of cargo-deny, which in my mind are

  1. Local use by a regular user
  2. Automated, typically CI

For the local use case, I think the defaults should be consistent with how other cargo subcommands work, which for each of those flags is an opt-in that the user makes a conscious decision to add. While it would be best if cargo-audit also followed this behavior (IMO), I'm not super concerned with that tool being different, as (I assume) you would either use cargo-deny or cargo-audit in a project, but not both.

For the automated use case, the use of opt-in flags means they are explicit and (hopefully) greppable in the VCS and/or automation configuration and gives the maximum flexibility in terms of how the automation is setup. The drawbacks of being explicit are of course that an actual decision needs to be made when setting up the automation to eg. pass --locked.

So there is definitely a conflict between the normal cargo default of needing to opt-in to --locked, but in CI a project will generally want to enable --locked (as well as the others if wanting to be network sandboxed), and either have a checked-in lockfile, or have an explicit lock generation step before cargo-deny is executed.

I think that one fairly simple solution to this conflict is to expose these 3 flags in the normal cargo-deny configuration, so that each project can configure them for all uses cases by default so that the local and automated use case match each other. This kind of goes against my point above about cargo-deny acting the same as other cargo subcommands, but I think this feels like a decent compromise between wanting to be consistent between usecases using a configuration file that a cargo-deny user will already need to create/edit anyhow, and already has eg. targets as a top-level field to influence the resolution behavior of the crate graph.

lfrancke

lfrancke

bug
0

Describe the bug

When copyleft is set to warn (which is the default) all the precedence checks after point 3 in this list https://embarkstudios.github.io/cargo-deny/checks/licenses/index.html#evaluation-precedence will not be considered anymore because warn is treated as allow:

https://github.com/EmbarkStudios/cargo-deny/blob/main/src/licenses/mod.rs#L127-L138

This basically resembles this config:

Expected behavior I would expect warn to behave like neither from allow-osi-fsf-free with an additional warning message: Fall through to the next check.

In theory I'd be happy to provide a PR but I haven't looked at the code yet on how to emit a warning and continue.

Device:

  • Version 0.9.1
jplatte

jplatte

enhancement
2

Is your feature request related to a problem? Please describe.

Sometimes, it is desireable to enforce certain (usually direct) dependencies are not in the dependency graph another time, while at the same time it is pretty much impossible to enforce that every crate is only present once in the depgraph.

Describe the solution you'd like

Allow banning multiple versions of specific crates (in addition to being able to set the lint level for any crate being in the depgraph multiple times).

jbg

jbg

enhancement
3

Is your feature request related to a problem? Please describe.

Occasionally we will try to debug an issue in a crate, and go looking for its source code, only to find that one of the following is true:

  1. The repository URL in Cargo.toml leads to a 404
  2. The repository URL in Cargo.toml points to a different fork of the crate, such that it does not correspond to the release we actually got from crates.io
  3. The repository URL in Cargo.toml is correct, but the release has been pushed to crates.io without the corresponding commits being pushed to the repository. (Surprisingly common with crates mostly maintained by one person who may forget to push.)
  4. The repository URL in Cargo.toml is correct, and the repository probably contains the commits, but it is difficult to determine which commit corresponds to the release, because of an absence of tags / commit messages / changelog entries that would make it obvious.

Describe the solution you'd like

Ideally we'd like to deny all of the above situations, since they are all difficult to distinguish from a malicious release.

(1) and (2) above seem quite achievable for cargo-deny to detect.

(3) and (4) could be more difficult. An approach could be taken that requires tags in the repository with a recognisable name format (0.1.2 or v0.1.2 seem most common), that correspond to releases in the crate registry. This would generate a lot of warnings at first, because many common crates do not consistently tag releases, but perhaps with some encouragement things could be improved there.

bnjbvr

bnjbvr

enhancement
3

Bytecode Alliance folks have ran into an interesting use case: a low-urgency sec-advisory that is fine to ignore for some time, but that should be re-reviewed some time later: https://github.com/bytecodealliance/wasmtime/pull/2881. To not forget about it, it'd be nice that cargo-deny can "ping back" after a given date, while ignoring the issue until the given date. Is that something that would make sense to add in cargo-deny?

(There's the question of which time zone should be applied to such a date, but any would work, really; I don't expect that being a day early or late in this kind of situation would be dramatic.)

Moxinilian

Moxinilian

bug
1

Describe the bug If a crate imported by path in the same workspace is mentioned in the ban deny list, cargo check will not error. This also seems to happen transitively.

To Reproduce

  1. Create a worspace with crateA and crateB.
  2. Make crateA have a path dependency on crateB by doing crateB = { path = "../crateB" }
  3. In the deny.toml of crateA, make crateB banned in the deny list.
  4. Ask for a cargo deny check on crateA from within crateA's folder.

Expected behavior cargo deny check should error as crateB is not allowed as a crateA dependency. Instead, checks pass.

Device:

  • OS: Linux

Additional context The reason I want to deny a crate from the same workspace as a dependency is that I am making a client and a server in the same workspace so they can share a common network crate. However when the workspace will inevitably have a more intricate dependency graph, I would like to ensure I don't accidentally link server code in the client.

nlewycky

nlewycky

enhancement
0

Is your feature request related to a problem? Please describe. We minimize multiple dependencies in our codebase as part of minimizing the size of our final binary. It'd be great if we could use cargo deny for this, but presently it issues errors on different versions of cfg-if crate which is only a dev-dependency.

Describe the solution you'd like Separate lint levels for multiple-versions that are going to be included in the build vs. multiple versions that are dev/build only.

The fact it's a dev-dependency are already included in the printout of the dependency structure when there is a conflict.

Describe alternatives you've considered Presently the workaround is to use skip to skip the whole crate as part of duplicate detection. This is OK to get started but not great long term.

Jake-Shadle

Jake-Shadle

enhancement
0

Right now, if you specify that you want to filter targets in the deny.toml with something like

cargo-deny will gather all of the dependencies for every crate, as long as they are pulled in by one or more of the specified triples (and matches the feature set, if they are optional). This however means that some portions of the crate graph are checked that are actually impossible in a real build context.

For example. lets look at a condensed version of

On Windows, the latest version, is used for all of the Windows specific APIs. This is good since the 0.2 version has severe compile time issues due to how the crate was structured, which is why we want to ban it from all of our codebases. However, because mio is used at the older 0.6 version for linux/BSD* when we unify targets we think that which is still used by that older mio version, is used, even though in the actual compile for Windows, we would only get the 0.3 version.

Instead of unifying all target platforms and checking a single giant crate graph that includes such erroneous subtrees, we should instead get a target specific graph for each target the user wants to check, and check each of them in parallel with each other so that we're only checking valid crate graphs.

Jake-Shadle

Jake-Shadle

enhancement
0

Right now we disregard all dev-dependencies for non-workspace crates as they aren't even actually used in the workspace itself, however it's quite often that dev-dependencies of the workspace pull in eg duplicates or other issues that, while they do affect the workspace, are less of a concern since they are not actually a part of the final binary output of the workspace.

Jake-Shadle

Jake-Shadle

enhancement
0

What features are enabled can have a significant impact on what cargo deny checks, eg, an optional dependency with a security vulnerability will not be checked if the feature that pulls that dependency in is not enabled by default.

Since we already support the normal feature toggles that most cargo subcommands support, we can support them as configuration values as well, that can be overriden by command line arguments. We would need to handle workspaces differently from specific crates as you can't toggle specific features on for workspaces however, which might be confusing to users.

Jake-Shadle

Jake-Shadle

enhancement
1

For most of the predicates checked by cargo-deny, an error condition can only arise if, in the lockfile case, 1 or more dependencies are updated, or, without a lockfile, a semver compatible version of 1 or more crates makes "breaking" change from cargo-deny's perspective, eg changing its licensing terms or similar. This basically means that, once a lockfile is present either because it's in source control, or is generated for the first time locally by a cargo operation, cargo deny will always report the same results as long as the lockfile and config file stay the same.

This, however, is not the case for diagnostics that come from an advisory database. As an advisory database is an external source of truth independent of the local project, and it is by default retrieved if not present (which is common in the CI case) or outdated, running cargo deny in a loop on the same lockfile and config file may not have the same results, since an advisory can be added to the remote database at any time that matches a crate in the dependency graph. This can be confusing for people in a larger team setting who may be doing any arbitrary change in a codebase, but then have cargo-deny start giving them a warning/error/CI failure that is completely unrelated to their change.

We should probably add an optional grace period of some kind in the advisories configuration that can downgrade diagnostics that would normally be errors down to warnings for any advisory that is newer than the advisory's creation timestamp + grace period so that cargo-deny doesn't emit an non-zero exit code. It could also just emit a different exit code, specified by the user, that they can treat differently from the normal non-zero exit code for failure as a kind of soft failure, or some other alert mechanism that they can react to differently than a regular build failure.

briansmith

briansmith

bug
1

Consider this:

Just from the length of the hash value, we can see that this isn't a secure hash. It seems like it wouldn't be too surprising for there to be even accidental collisions in the hash value. Also, reading the source code I see a non-secure hash algorithm is used. It could be important for a user who is trying to satisfy legal requirements for license compliance to use a secure hash, even though it might otherwise be considered overkill. Plus, I think it is just good practice.

I suggest the following improvement: 0. Implement a new style of hash that is a full SHA-384 of the license file.

  1. Change the documentation and all examples to use these new SHA-384 hashes.
  2. (Optional) Deprecate the old style hashes. Warn when they are encountered and suggest the new style of hash with the appropriate value, but still report success. Provide a command-line flag to force the use of the strong hashes.
  3. At some point, perhaps immediately, remove support for the old style hashes.

I would be happy to help review a change of this sort.

zicklag

zicklag

bug
2

Describe the bug

When running cargo deny check on a computer behind an HTTP proxy that requires authentication I get this error about 50% of the time:

To Reproduce Steps to reproduce the behavior:

  1. Set http_proxy and https_proxy environment variables in the format http://user:[email protected]:port poin
  2. Run cargo deny check in a project
  3. See error

Expected behavior No error should be displayed and the process should not abort.

Device:

  • OS: Ubuntu 20.04 ( Pop!_OS variant )

Additional context I've used cargo deny a while ago ( ~ 6 months, maybe :man_shrugging: ) and I didn't have that problem, then.

Jake-Shadle

Jake-Shadle

enhancement
5

Right now, the cargo-deny-action repo uses a dockerfile for the action, but this means that it gets built from scratch every time, which is inefficient, even if takes <30s, instead, we should publish an image to the Github Container Registry for every version of cargo-deny that it can use instead.

Versions

Find the latest versions by id

0.11.4 - Apr 11, 2022

Fixed

  • PR#414 resolved #484 by always sorting crates with the same name by their version so they are always deterministically sorted. Thanks @Veykril!
  • PR#418 fixed an issue where duplicate crate versions would not be detected if the crate was sorted last in the crate graph.

Changed

0.11.3 - Feb 14, 2022

Fixed

  • PR#407 resolved #406 by always checking license exceptions first.

0.11.2 - Feb 07, 2022

Changed

Fixed

  • PR#398 resolved #135 by making [licenses.exceptions] additive to the global allow list. Thanks @senden9!
  • PR#404 resolved #401 by trimming quotes from spans before serializing them as JSON.
  • PR#404 resolved #402 by updating crossbeam-utils to a non-yanked version.

0.11.1 - Jan 28, 2022

Added

  • PR#391 resolved #344 by adding [licenses.ignore-sources] to ignore license checking for crates sourced from 1 or more specified registries. Thanks @ShellWowza!
  • PR#396 resolved #366 by also looking for .deny.toml in addition to deny.toml if a config file is not specified.

Changed

  • PR#392 updated all dependencies.

Fixed

  • PR#393 resolved #371 by changing the default for version requirements specified in config files to accept all versions, rather than using the almost-but-not-quite default of *.
  • PR#394 resolved #147 by ignore all private crates, not only the ones in the workspace.
  • PR#395 resolved #375 by fixing a potential infinite loop when using [bans.skip-tree].

0.11.0 - Dec 06, 2021

Changed

  • PR#382 updated dependencies and bumped the Minimum Stable Rust Version to 1.56.1.

0.10.3 - Nov 22, 2021

Changed

  • PR#379 updated askalono which got rid of the failure dependency, which was pulling in a lot of additional crates that are now gone.

Fixed

  • PR#379 fixed #378 which was an edge case where the sources check was executed against a crate that didn't use any crates from crates.io, and the config file was shorter than the crates.io URL.

0.10.2 - Nov 21, 2021

Fixed

  • PR#376 fixed the JSON formatting when using --format json output option. Thanks @dnaka91!

Changed

  • PR#377 updated dependencies.

0.10.1 - Nov 10, 2021

Fixed

  • PR#347 resolved #372 by correcting a slight mistake that resulted in an incorrect hash making cargo-deny unable to lookup index or crate information from the local file system.

0.10.0 - Oct 29, 2021

Added

Changed

  • PR#358 bumped the Minimum Stable Rust Version to 1.53.0.
  • PR#358 bumped various dependencies, notably semver to 1.0.3.

0.9.1 - Mar 26, 2021

Changed

  • Updated dependencies

0.9.0 - Mar 11, 2021

Changed

  • Updated krates, which in turn uses an updated cargo_metadata which uses camino for utf-8 paths. Rather than support both vanilla Path/Buf and Utf8Path/Buf, cargo-deny now just uses Utf8Path/Buf, which means that non-utf-8 paths for things like your Cargo.toml manifest or license paths will no longer function. This is a breaking change, that can be reverted if it is disruptive for users, but the assumption is that cargo-deny is operating on normal checkouts of rust repositories that are overwhelmingly going to be utf-8 compatible paths.

0.8.9 - Mar 08, 2021

Fixed

0.8.8 - Feb 25, 2021

Changed

  • Updated dependencies, notably cargo and rustsec.
  • Increase MSRV to 1.46.0 due to bump of smol_str/rustsec.
  • Updated SPDX license list supported from 3.8 to 3.11 due to update of spdx.
  • Add use of the --locked flag in all cargo install instructions, to avoid the default (broken) behavior as shown in #331.

0.8.7 - Feb 18, 2021

Fixed

  • Resolved #331 by updating bitvec and funty.

0.8.5 - Dec 15, 2020

Added

  • PR#315 resolved #312 by adding support for excluding packages in the deny configuration file, in addition to the existing support for the --exclude CLI option. Thanks @luser!

Fixed

  • PR#318 fixed #316 by adding a workaround for crate versions with pre-release identifiers in them that could be erroneously marked as matching advisories in an advisory database. Thanks for reporting this @djc!

0.8.4 - Nov 11, 2020

Changed

  • Updated dependencies, notably rustsec, crossbeam*, and cargo.
  • Bumped the Minimum Stable Rust Version to 1.44.1.

0.8.3 - Nov 10, 2020

Fixed

  • Fix deny.template.toml to use db-urls instead of db-url.

0.8.2 - Oct 22, 2020

Fixed

  • PR#303 fixed #302 by reverting an unintended behavior change in how the default path for advisory databases was resolved.

0.8.1 - Oct 21, 2020

Fixed

  • PR#297 fixed a couple of diagnostics to have codes.
  • PR#296 resolved #288 by improving the information in diagnostics pertaining to advisories. Thanks @tomasfarias!

0.8.0 - Oct 20, 2020

Added

  • PR#238 resolved #225 by adding a wrappers field to [bans.deny] entries, which allows the banned crate to be used only if it is a direct dependency of one of the wrapper crates. Thanks @Stupremee!
  • PR#244 resolved #69 by adding support for multiple advisory databases, which will all be checked during the advisory check. Thanks @Stupremee!
  • PR#243 resolved #54 by adding support for compiling and using cargo crate directly via the standalone feature. This allows cargo-deny to be used without cargo being installed, but it still requires rustc to be available. Thanks @Stupremee!
  • PR#275 resolved #64 by adding a diagnostic when a user tries to ignore an advisory identifier that doesn't exist in any database.
  • PR#262 added the fix subcommand, which was added to bring cargo-deny to feature parity with cargo-audit so that it can take over for cargo-audit as the official frontend for the the RustSec Advisory Database.

Changed

  • advisories.db-url has been deprecated in favor of advisories.db-urls since multiple databses are now supported.
  • advisories.db-path is now no longer the directory into which the advisory database is cloned into, but rather a root directory where each unique database is placed in a canonicalized directory similar to how .cargo/registry/index directories work.
  • PR#274 resolved #115 by normalizing git urls. Thanks @senden9!

Fixed

  • #265 A transitive dependency (smol_str) forced the usage of the latest Rust stable version (1.46) which was unintended. We now state the MSRV in the README and check for it in CI so that changing the MSRV is a conscious decision.
  • PR#287 fixed #286, which could happen if using a git source where the representation differed slightly between the user specified id and the id used for dependencies.
  • PR#249 fixed #190 by printing a different diagnostic for when the path specified for a clarification license file could not be found. Thanks @khodzha!

0.7.3 - Aug 06, 2020

Added

  • PR#237 added the ability to allow git sources from entire github.com, gitlab.com, or bitbucket.org organizations.
  • PR#237 added the ability to lint the specifiers used for git sources.

0.7.2 - Jul 28, 2020

Added

  • PR#227 Added a new bans.wildcards check to lint for version requirements of "*", which can happen when using local or patched crates that aren't published to a registry. Thanks @khodzha!

Fixed

  • Fix incompatible crate versions due to cargo_metadata.

0.7.1 - Jul 28, 2020

Fixed

  • Fix issue due to incompatible semver versioning with relation to...the semver crate.

0.7.0 - Jun 25, 2020

Added

  • Resolved #137 by adding a --format <human|json> option. All diagnostic and log messages from the check subcommand respect this flag.

Changed

  • Resolved #216 by adding support for the --all-features, --features, and --no-default-features flags to specify the exact features to have enabled when gathering the crates in your dependency graph to actually run checks against. This is a BREAKING CHANGE as previously crates were gathered with --all-features.
  • The --color option for the list subcommand has been moved to the top level arguments.

Removed

  • The --context option , which was deprecated in 0.6.3, has been removed.

Fixed

  • Resolved #211 by adding a top-level --color <auto|always|never> option, if stderr is not a TTY or never is passed, no colors will be present in the output stream.

0.6.8 - Jun 06, 2020

Added

  • A one line summary of the state of each check is now output at the very end of the check subcommand unless the --log-level is off. If the --log-level is info or higher, a summary of the state, errors, warnings, and notes for each check are outputted on their own line instead.
  • Added the -s | --show-stats flag to the check subcommand, which will print out the more detailed summary, regardless of the --log-level.

Changed

  • Updated crates.
  • Updated cfg-expr, which should allow for filtering of crates for most custom targets that aren't built-in to rustc.

0.6.7 - May 02, 2020

Fixed

  • PR#183 resolved an infinite loop issue which could be caused by cyclic dependencies in a crate graph. Thanks @Veetaha!

0.6.6 - Feb 25, 2020

Changed

  • Updated crates. Mainly to force a new version because the Windows release messed up. Yay!

0.6.5 - Feb 25, 2020

Added

  • Added a fetch subcommand that can be used to fetch external data, currently the crates.io index and the configured advisory database

Changed

  • Upgraded to rustsec 0.18.0, which slighly reworks how yanked crate detection is done

0.6.4 - Feb 08, 2020

Fixed

  • Resolved #131 by removing an unnecessary path canonicalization

0.6.3 - Feb 05, 2020

Added

  • Added the --manifest-path option to specify the Cargo.toml you want to use as the context for the operation to fit with how other cargo subcommands work. Takes precedence over the (deprecated) --context.
  • Added the --workspace flag to give the user a workaround in cases where a manifest is both a package and a workspace.
  • Added the --exclude option to allow users to explicitly remove packages from the final crate graph.

Changed

  • The configuration used for the command is recursively searched for in parent directories starting in the same directory as the Cargo.toml (unless explicitly specified).
  • The target list used when evaluating cfg expressions for dependencies has been updated to the list of targets supported by 1.41.0. This will give undesired behavior if you happen to use a target triple that has been removed from 1.41.0 that is available in the Rust version you have.

Fixed

  • Resolved #122 by pruning the packages that are checked against the advisory database to the same set used by all other checks

Deprecated

  • --context has been deprecated in favor of --manifest-path, to align cargo-deny more with all other cargo subcommands

Information - Updated May 13, 2022

Stars: 816
Forks: 41
Issues: 52

A fantasy deathcrawl in Rust

To run, with Rust compiler and Cargo package manager installed:

A fantasy deathcrawl in Rust

cargo-ndk - Build Rust code for Android

This cargo extension handles all the environment configuration needed for successfully building libraries

cargo-ndk - Build Rust code for Android

quest-hook-template

A template for writing mods for Quest il2cpp games in Rust using cargo generate to clone the template:

quest-hook-template

Command line json text parsing and processing utility

parsing json compliant with rust and cargo

Command line json text parsing and processing utility

Clone this repo: git clone

If you don't have Rust and cargo-make installed,

Clone this repo: git clone

Rustup: the Rust installer and version management tool

To test that you have Rust and Cargo installed, you can run this in your terminal of choice: cargo --version

Rustup: the Rust installer and version management tool

Address generator in Rust

If you have Rust: cargo install gemgen

Address generator in Rust

First, complete the basic Rust setup instructions

Use Rust's native cargo command to build and launch the template node:

First, complete the basic Rust setup instructions

Use one mouse on multiple computers

In France, we call that &quot;flemme&quot; (install cargo for rust)

Use one mouse on multiple computers

Build tool for deploying Rust WASM repositories to Screeps game servers

Build tool for deploying Rust WASM repositories to cargo-web, adding the ability to trim node

Build tool for deploying Rust WASM repositories to Screeps game servers

cargo rssc - Rust scripts for crates building

will copy the template_basic into scripts_rssc folder

cargo rssc - Rust scripts for crates building
Facebook Instagram Twitter GitHub Dribbble
Privacy