rustsec/rustsec

RustSec Crates 🦀🛡️📦

The RustSec Advisory Database is a repository of security advisories filed

RustSec Crates 🦀🛡️📦

The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via crates.io.

The advisory database itself can be found at:

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

About this repository

This repository contains a Cargo Workspace with all of the crates maintained by the RustSec project:

Name Description Crate Documentation Build
cargo‑audit Audit Cargo.lock against the advisory DB
cargo‑lock Self-contained Cargo.lock parser
cvss Common Vulnerability Scoring System
platforms Rust platform registry
rustsec Advisory DB client library
rustsec‑admin Linter and web site generator

License

All crates licensed under either of

  • Apache License, Version 2.0
  • MIT license

at your option.

Issues

Collection of the latest Issues

joao-paulo-parity

joao-paulo-parity

Comment Icon1

Thanks for this package.

https://github.com/paritytech/polkadot/pull/5731#issuecomment-1168307056 showcases a difficult-to-debug error (the resolution is described in https://github.com/paritytech/parity-processbot/issues/392#issuecomment-1180262524 in case you're curious)

Failed to parse lockfile of polkadot: Error { kind: Parse, msg: "parse error: ambiguous dependency: windows-sys" }

I find unintuitive that it's called a "parse error" when I infer this is actually a dependency resolution error (https://github.com/paritytech/parity-processbot/issues/392#issuecomment-1180262524). Also I couldn't understand why cargo-lock is caring about dependency resolution since we intend to use it only for parsing.

The error comes from this line

https://github.com/rustsec/rustsec/blob/e997762da245a4b20e4245c2d6a3788a061dc5bd/cargo-lock/src/error.rs#L27

And I guess it's related to this

https://github.com/rustsec/rustsec/blob/e997762da245a4b20e4245c2d6a3788a061dc5bd/cargo-lock/src/error.rs#L39

If I could suggest improvements:

  1. The error message should provide more precise debugging information. e.g. it would be better if it could tell which line had the problem or at least if it said "windows-sys (dependency of xxx)".
  2. The cargo-lock library should provide a configuration option for being limited to parsing only; in that case it shouldn't care about ambiguous dependencies or anything else other than parsing the file. (Is that sane?)
Xuanwo

Xuanwo

Comment Icon2
vi

vi

Comment Icon3

If cargo audit signals a problem and I do not want to update that dependency (e.g. due to MSRV or executable size or excessive delta concerns), then, as far as I understand, I am supposed to review each usage of the vulnerable crate (including in transitive dependencies), then add the report to .cargo/audit.toml's ignore section.

But after introducing some new crate, vulnerable crate may gain another, new incoming dependency in the lockfile, which was not reviewed when RUSTSEC was originally ignored; and cargo audit will continue to ignore the report even though that new transitive dependency may use it in a really vulnerable way.

Shall cargo audit allow narrowing ignore rules to only specific versions of specific dependencies using the vulnerable crate, not the only globally for the whole project?

danielhaap83

danielhaap83

Comment Icon0

Hi, fetching a private git repository fails using https and gits credential.helper = store.

Example code:

Error

Expected Clones my private repository at tmp directory.

Authentication Verified Git clone using executable from shell works.

Prerequisite

  1. repository with visibility set to private
  2. git credential helper store configured: git config --global credential.helper store
  3. git credential helper store enabled
  • 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

Versions:

  • Ubuntu 20.04.4 LTS
  • git executable version 2.25.1
  • rustsec 0.25
keltia

keltia

Comment Icon0

I'm using ssh as a SOCKS proxy for everything curl and git-related. This works fine but after installing cargo-audit the command fails to fetch the db:

I have these settings in my global .gitconfig file:

If I try to change http.proxy into the same settings as https.proxy it fails too:

Any advice? I live behind an authenticated proxy so Im mostly using SOCKS. All other cargo commands work fine.

safinaskar

safinaskar

Comment Icon0

When I run cargo audit -v, I see strange error message:

I. e. cargo-audit complains that it doesn't understand -v, but then immediately says that -v is permitted

nathan-at-least

nathan-at-least

Comment Icon5

Advisory Impact Standard

Is there a standard for documenting how upstream dependency vulnerabilities impact a given crate, so that users of the crate know (a) the authors are aware and (b) they have some guidance on the impact for the dependent crate/binaries?

This is an idea that's been percolating for me and I'm posting it here because if there's already something like this (I haven't found it yet) it seems like this project would know, and if there is not, maybe this set of developers is best positioned to define it.

Motivation

Dependent Crate Developers

Suppose you develop a crate A that has a transitive dependency on B and B has an outstanding advisory. What should the A developer do? Assume they can't reasonably contribute to B's vulnerability resolution on a timeline that works for their needs for A.

  • They should probably first try cargo update and see if that pulls in a resolution to the vulnerability. By far the best option.
  • If that fails, they might find an alternative dependency subtree to switch to which does not have an advisory. This may be fairly invasive, depending on the alternative's API differences. This may in turn impact A's interface and complicate the decision making around semver semantics. However, sometimes, it may work out well enough.
  • If both of the above do not work, they should investigate precisely how the vuln in B impacts A in any case any downstream user may exercise, then document that.

The idea here is to standardize that documentation for both users and automated tools.

Dependent Crate Consumers

Now suppose you are a consumer of crate A, and you regularly run cargo audit, like a good citizen, and you see that one of its transitive dependencies has an outstanding vulnerability disclosure. What should you do?

  • First, you probably want to know if the A developers are even aware of the issue. If they are not, that's concerning, and implies the impacts on A haven't been investigated adequately. A good step here might be to file a ticket requesting that they document an impact analysis.
  • Next, suppose the developers are aware and have documented how this impacts the use of A. This is the best case! Now you need to determine if your own use is safe (whether as a downstream crate dev, or a user of the binaries).

Ecosystem Safety Infrastructure

Finally, suppose you are providing infrastructure to improve safety across the ecosystem. You may want a way to scan many crates for impact statements on any particular advisory, or all advisories. Perhaps you want to add badges to repositories, doc sites, or package distribution sites.

Specification Brainstorm

I envision a specification that can help dependent crate developers and users track the impacts of upstream vulnerabilities, so here's a sketch:

  • Define a standard path for documenting vulnerability impacts, such as ./doc/vulnerabilities.md.
  • Define a human-readable format with well-defined embedded metadata. Maybe this is markdown with some unambiguously parseable way to associate impact analysis documentation to the advisories themselves.
  • Create a feature of cargo-audit or a downstream tool (ex cargo-audit-impacts) which compares the audit report against the impact document, and warns/errors users where there are advisories with no associated impact section, or where there are impact sections that are no longer relevant.

In addition to those tool-centric bullets, the idea is a user who doesn't use cargo at all can simply browse the markdown to get a concise overview of advisory impacts, say by browsing github or another source mirroring website.

It may be useful to have a standardized set of impact assessment field values, such as UNKNOWN, NO IMPACT, CONDITIONAL IMPACTS, COMPREHENSIVE IMPACT. "Conditional" means that only some subsets of an API or binary usage under some conditions are vulnerable, in which case the details need to spelled out in natural language suitable for the crate/binary consumers. Meanwhile, "comprehensive" means many or most uses of the dependent crate are likely to be vulnerable to the issue. (Names are hard, I'm not wed at all to them.)

Thoughts?

Does this already exist?

Does this general approach seem like a useful thing to put effort into?

If so, I'd like to ensure the standard and cargo-audit interface well with each other, including backwards compatibility / future-proofing considerations.

tmfink

tmfink

Comment Icon0

cargo-audit always uses ANSI color escape codes, even when --color=auto.

Actual Behavior

It seems that the NO_COLOR environment variable is respected:

Desired Behavior

When --color=auto, ANSI escape codes should only be used when writing directly to a console (not when output redirected to a file or piped to another program).

0xpr03

0xpr03

Comment Icon2

It would be nice to prevent ci from failing on dev dependencies, especially for external examples.

Example this will always fail but is totally irrelevant for the security of notify itself. Otherwise I'll have to remove user examples when they get unmaintained sub-dependencies in big, slow moving frameworks like tide.

mathstuf

mathstuf

Comment Icon7

GitLab supports rendering the results of dependency scanning with the code itself. It'd be nice if cargo-audit could be coerced to write it in the format that GitLab understands. If not, getting GitLab to natively understand or transmogrify the output for its purposes would be sufficient as well.

Documentation for the feature on GitLab: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html#reports-json-format

epage

epage

Comment Icon0

Similar to the crate registry (see #489), it looks like fetching the rustsec DB is vulnerable to failing on the same race condition. We should support retries, whether inside rustsec or by providing enough context to the user so they know they should attempt a retry (looks like all we can tell is there is a "repo" error).

carlosb1

carlosb1

Comment Icon18

I has an error with the cargo-audit

version rustc: 1.56.1 version cargo: 1.56.0

For a docker image rust:alpine, I install audit and then:

I apply these commands in the docker image before install audit:

For running the docker image, I run:

Some idea?

UPDATE It happens in the alpine image... for debian based image didn't throw the error.

Shnatsel

Shnatsel

Comment Icon0

Sometimes people specify patched versions with an upper bound, e.g. using the ^ operator, so that all currently existing versions are covered, but versions released in the distant future would be marked as unpatched.

This is clearly unintentional unless there are no patched versions, but is easy to miss in manual review.

Examples where this was initially missed: https://github.com/RustSec/advisory-db/pull/951 https://github.com/RustSec/advisory-db/pull/945

We should add a lint that warns about this (unless patched = []).

alan-signal

alan-signal

Comment Icon0

0.14.1

Reproduction steps

  1. Create a repo with a warning, e.g.:

  2. Run $cargo audit and see the warning.

  3. Promote that warning to an error and see the error $cargo audit --deny warnings.

  4. Now run with and without --deny warnings and --json.

$ cargo audit --json $ cargo audit --deny warnings --json

Expect

The warning to be promoted to an error in the json.

Actual

No difference is seen, it remains a warning:

Additionally, you can reproduce this with a .cargo/audit.toml:

Consequences

The audit-check which uses --json cannot be made to fail on warnings. See: https://github.com/actions-rs/audit-check/issues/132 (audit-check requires that it is solved for the .cargo/audit.toml case.)

I have not investigated whether other relevant command line/audit.toml options are respected in json output when they should be.

An MCVE is here: https://github.com/alan-signal/cargo-audit-action/pull/1 with the issue as seen with audit-check.

ebeasant-arm

ebeasant-arm

platforms-crate
Comment Icon2

The list maintained at https://doc.rust-lang.org/nightly/rustc/platform-support.html includes a couple of Tier-1 and Tier-2 platforms that are not recognised (in 1.1.0) or are in different tiers compared with platforms-crate. This is given as the reference list for the Platforms crate.

When building crates that check the current platform (find or guess_current) against the list, this is causing failures on some devices.

A re-sync pf platforms-crate to the master list (above) would fix this, and a release would be really helpful.

surechen

surechen

Comment Icon2

Hi, when I use "cargo audit", I get an error :

audit Fetching advisory database from https://github.com/RustSec/advisory-db.git error: couldn't fetch advisory database: git operation failed: unknown http scheme 'socks5'; class=Http (34)

I use github through a proxy : http.proxy=#404 https.proxy=#404

Can you help me with this problem?

Versions

Find the latest versions by id

Information - Updated Jul 31, 2022

Stars: 1.1K
Forks: 81
Issues: 58

Repositories & Extras

Rocket is an async web framework for Rust with a focus on usability, security,

Visiting localhost:8000/hello/John/58, for example, will trigger the hello

Rocket is an async web framework for Rust with a focus on usability, security,

Rust bindings for the C++ api of PyTorch

LIghtweight wrapper for pytorch eg libtorch in rust

Rust bindings for the C++ api of PyTorch

Know the exact crate versions used to build your Rust executable

Audit binaries for known bugs or security vulnerabilities in production, at scale, with zero bookkeeping

Know the exact crate versions used to build your Rust executable

macOS/iOS Security framework for Rust

MIT license (LICENSE-MIT or

macOS/iOS Security framework for Rust

Reference implementation of the Stacks blockchain in Rust

Reference implementation of the Proof of Transfer (PoX) mining that anchors to Bitcoin security

Reference implementation of the Stacks blockchain in Rust

osu! server written in Rust

Fully asynchronous, high concurrency, high performance, and high security

osu! server written in Rust

Nakamoto is a privacy-preserving Bitcoin light-client implementation in Rust,

with a focus on low resource utilization, modularity and security

Nakamoto is a privacy-preserving Bitcoin light-client implementation in Rust,

A WIP Rust implementation of Messaging Layer Security based on draft 9+

Messaging Layer Security based on draft 9+

A WIP Rust implementation of Messaging Layer Security based on draft 9+

Rust Language Security

execrices: RUSTSEC-2021-0001

Rust Language Security

security-keys-rust

Many thanks to the authors of the openpgp-card Rust crate

security-keys-rust

Owlyshield open source security platform

An OSS security platform written in rust with security threat detection

Owlyshield open source security platform

Reference implementation of the Stacks blockchain in Rust

Reference implementation of the Proof of Transfer (PoX) mining that anchors to Bitcoin security

Reference implementation of the Stacks blockchain in Rust
Facebook Instagram Twitter GitHub Dribbble
Privacy