rustsec / advisory-db Goto Github PK

Example:
https://rustsec.org/advisories/RUSTSEC-2019-0005.html

&str is rendered as &str

Hi! I can't access the address https://rustsec.org

I thought it was only me, but according isitdownrightnow, the website is down for everyone.

https://www.isitdownrightnow.com/rustsec.org.html

https://crates.io/crates/fake-static is created as a demonstration of a soundness bug in rustc that lets you invoke undefined behavior in safe code. The entire point of the code is to obtain use-after-free without writing unsafe. No production code should ever depend on this.

It appears tools like Snyk keep track of CVSS data. It would be nice if we could provide that for Rust code, too.

The net2 crate is deprecated. The previous release was in June 2018, however, it currently has over 22000 downloads per day.

The template file has the following section in it, which is marked as being mandatory.

# Versions which include fixes for this vulnerability (mandatory)
[versions]
patched = [">= 1.2.0"]

How do we disclose vulnerabilities that haven't yet been patched? I'm specifically thinking of all of the following cases:

• You discover a serious security hole that can be temporarily worked around by changing firewall settings, or disabling an optional feature.
• You've wrapped an external library (e.g. C/C++) and it has the vulnerability, which you're now exposing to your users. You don't have control over the wrapped library, so all you can do is warn the users about it.
• You discover that your public API is buggy, but can't change it without forcing a major update. Instead of rushing to a new API, you choose to disclose the fact that the current API is buggy so that users avoid the buggy parts while you design a better API.

If this section were optional, then the assumption could be that the vulnerability has not yet been patched. Alternatively, you may wish to update the template (and possibly the code) to permit an empty list, which indicates that it hasn't yet been patched.

There is presently no way to browse the vulnerability database other than by reading the individual TOML files in the repository.

It would be nice to render all of the vulnerabilities such that they have a directly linkable advisory URL. This could be done using e.g. GitHub pages or Firebase such that the content is automatically rebuilt in CI.

Another alternative is to render content for the advisory-db Wiki

Hello, thank you for maintaining cargo audit, it's a great idea!

I noticed this error appeared about 10 minutes ago.

RustPräzi is a crater-like tool which builds a call graph across all of the crates published to crates.io:

https://internals.rust-lang.org/t/prototype-dev-tool-rustprazi-a-tool-to-build-an-entire-call-graph-of-crates-io/8912

It would be interesting to use this tool, perhaps in conjunction with crates-audit, to generate a list of impacted crates based on this call graph.

To do that we'd need to collect structured information about vulnerable functions in advisories. Looking at our existing advisories, that information is often already there, but buried in an unstructured prose description, e.g.:

https://rustsec.org/advisories/RUSTSEC-2018-0003

If an iterator passed to SmallVec::insert_many panicked in Iterator::next, destructors were run during unwinding while the vector was in an inconsistent state, possibly causing a double free (a destructor running on two copies of the same value).

I think it'd be good to come up with a structured format for this sort of information that can be fed into tools like RustPräzi to determine impacted users of vulnerable crates.

The description contains the text:

Serializing of headers to the socket did not filter the values for newline bytes (\r or \n),

The \r and \n are parsed as actual escaped cr/lf, and so the description is printed as:

 or alizing of headers to the socket did not filter the values for newline bytes (
),
which allowed for header values to split a request or response. People would not likely include

I'm not sure if this intended in the format of description, or if this is a bug in the rustsec crate. As far as I can tell, it isn't possible to print the description with cargo audit, so maybe this has been overlooked.

All versions of Hyper prior to 0.9.4 do not do hostname validation and used insecure cyphers and had compression enabled.

https://github.com/hyperium/hyper/blob/master/CHANGELOG.md#v094-2016-05-09

Version 0.9.5 disabled hostname validation on Windows because it wasn't working.

Though as of version 0.10.0, rust-openssl was ripped out and now the user is responsible for choosing a TLS library.

https://github.com/RustSec/advisory-db/blob/aa789b9cbd6a03c860c7a1f508cb60ae9f22e3eb/crates/plutonium/RUSTSEC-2020-0011.toml#L5 has the field obsolete , upon grepping the repo, I found this as the only advisory containing this field.

If it is planned to add this field in the schema , please add that to README , that would be very helpful detail for us at https://github.com/nexB/vulnerablecode as we are essentially consuming this repo. Thanks.

dwf is a toplevel key in advisories which stands for "Distributed Weakness Filing". The idea was that DWF could be a superset of CVE, and we could potentially get our own ID block so we could use DWFs as the canonical identifiers. However, it seems DWF has largely boiled down to https://iwantacve.org/

I think we should change the dwf, but I think we can do something a little more futureproof and interesting: add two new optional toplevel keys to advisories:

• aliases: an array of vulnerability identifiers which identify the same vulnerability as this one
• references: vulnerability identifiers which are related to this one, but not the same

I'm not sure there's really any need to prefix or namespace them, since they pretty much always include a namespace as part of the ID.

Example:

aliases = ["CVE-2017-1000168"]
references = ["CVE-2017-0379"]

I was just reading https://snf.github.io/2019/01/10/rust-2019-security/ and I was wondering what would be the best way to integrate advisory-db with cargo crev. The most natural way seems to be to have official advisory-db CrevId. It seems like advisory format fits quite well into crev's Package Review Proof format.

We could start by preparing a converter from the existing format to crev proofs.

Would there be a will to integrate these two projects? If there was, I could "hardcode"/auto-suggest such an Id to all users of cargo-crev. If not, I guess I could run such an Id as a part of crev project too.

Please let me know your thoughts!

Discussion here:

https://internals.rust-lang.org/t/failure-crate-maintenance/12087/16?u=bascule

failure is a fairly pervasive crate and marking it as unmaintained immediately would be rather noisy.

On the discussion thread above I suggested waiting for some period of time for people to organically migrate to new crates, then filing an advisory.

Perhaps 3 months is enough time? (so August 2020)

See: rust-lang/rust#63791

I think it makes sense to encourage people to yank all releases of any crate which match any vulnerable versions listed in advisories.

This could range from a heavy-handed lint on published crate versions which requires all impacted versions for a crate be yanked before the advisory can be merged, to a lighter touch "you should probably yank those crates" advice in both CONTRIBUTING.md and as a pull request comment.

What do people think about this?

The patched_versions in hyper/RUSTSEC-2017-0002.toml has a couple of ranges in the same item, and is the only file like that:

advisory-db $ grep -r patched crates/*
crates/arrayfire/RUSTSEC-2018-0011.toml:patched_versions = [">= 3.6.0"]
crates/base64/RUSTSEC-2017-0004.toml:patched_versions = [">= 0.5.2"]
crates/claxon/RUSTSEC-2018-0004.toml:patched_versions = ["=0.3.2", ">= 0.4.1"]
crates/cookie/RUSTSEC-2017-0005.toml:patched_versions = ["< 0.6.0", "^0.6.2", ">= 0.7.6"]
crates/crossbeam/RUSTSEC-2018-0009.toml:patched_versions = [">= 0.4.1"]
crates/hyper/RUSTSEC-2017-0002.toml:patched_versions = [">= 0.10.2", "< 0.10.0, >= 0.9.18"]
crates/hyper/RUSTSEC-2016-0002.toml:patched_versions = [">= 0.9.4"]
crates/openssl/RUSTSEC-2018-0010.toml:patched_versions = [">= 0.10.9"]
crates/openssl/RUSTSEC-2016-0001.toml:patched_versions = [">= 0.9.0"]
crates/orion/RUSTSEC-2018-0012.toml:patched_versions = [">= 0.11.2"]
crates/safe-transmute/RUSTSEC-2018-0013.toml:patched_versions = [">= 0.10.1"]
crates/security-framework/RUSTSEC-2017-0003.toml:patched_versions = [">= 0.1.12"]
crates/serde_yaml/RUSTSEC-2018-0005.toml:patched_versions = [">= 0.8.4"]
crates/slice-deque/RUSTSEC-2018-0008.toml:patched_versions = [">= 0.1.16"]
crates/smallvec/RUSTSEC-2018-0003.toml:patched_versions = [">= 0.6.3", "^0.3.4", "^0.4.5", "^0.5.1"]
crates/sodiumoxide/RUSTSEC-2017-0001.toml:patched_versions = [">= 0.0.14"]
crates/tar/RUSTSEC-2018-0002.toml:patched_versions = [">= 0.4.16"]
crates/trust-dns-proto/RUSTSEC-2018-0007.toml:patched_versions = [">= 0.4.3", ">= 0.5.0-alpha.3" ]
crates/untrusted/RUSTSEC-2018-0001.toml:patched_versions = [">= 0.6.2"]
crates/yaml-rust/RUSTSEC-2018-0006.toml:patched_versions = [">= 0.4.1"]

crates/hyper/RUSTSEC-2017-0002.toml:patched_versions = [">= 0.10.2", "< 0.10.0, >= 0.9.18"]

Is this intended, or is it a bug?

It has been pointed out that we currently do not carry any advisories for Actix, even though some versions of it contain unsafe code that is known to be problematic. We should notify people about the issues, starting with the very old, uncontroversially problematic versions. Advisories for more recent versions should probably be coordinated with Actix maintainers.

By looking at this repository I do not see any answers to the following questions:

1. How do I file an advisory? (Presumably by opening a PR, but it's not stated)
2. Under what conditions should I file an advisory? Is a panic eligible for an advisory? Memory leak? Math that calculates buffer sizes incorrectly but is not dangerous unless fed to unsafe by API consumer? I've already found all of these.
3. What do I do if the crate maintainers are not responding / fixing the issues? My experience with filing bugs has ranged from best response I've seen yet to pretty much ignored.

The reason I'm asking is that I've spent the last several days fuzzing various popular library crates, so now I'm sitting on a pile of bugs, wondering what to do with them aside of fixing them and opening PRs in absence of action from maintainers.

Also, somewhat out of scope of this issue:

• I have looked for a place to report security issues in Rust packages on crates.io and found nothing of use. There is security page for Rust itself that does not mention anything about crates.io packages. If I'd found something more serious than panics or OOMs that I got so far, I would not be able to report it anywhere, as my experience with CVEs so far can be summed up as "don't even bother".
• I have failed to find a guide for shipping security updates on crates.io. Do I yank the vulnerable versions? How do I announce that a certain update is a security update? What other steps do I need to take?
• This is the first time I hear about cargo-audit, despite being security-inclined. Cargo quickstart guides did not mention it. Neither did the Nomicon mention any kind of actions to take after you've found and fixed a memory safety issue. The folks over at rust-fuzz make no mention of this either.
• I kind of expected cargo to notify me about security updates for dependencies of my crate without me invoking obscure tools. It's not like I can run cargo audit on everything twice a day, even if I'd known about it. Yet the readme for it says it doesn't even ship with cargo by default?
• As an aside, I hope something like email updates is set up for maintainers of crates on crates.io shipping with cargo.lock pointing to vulnerable versions and cargo.toml to vulnerable series, but I am not one of them, so I wouldn't know.

Happened in #70 -- the package didn't match the one on crates.io

I was recently complaining on how core ecosystem crates like term are unmaintained. Someone responded with an interesting idea: have RustSec track this information and expose it through cargo-audit.

Here is a broad strokes sketch of how I think this could work:

• Define a policy for what counts as an "unmaintained crate" (see below)
• In this repo, create a crates/<unmaintained_crate>/unmaintained.toml file containing information about the crate's current status.
• Surface this information as a warning in cargo-audit with an option to make it an error.

What policy makes sense for an unmaintained.toml? Well, the term crate is pretty clear-cut, the maintainer posted a "Looking For Maintainer (LFM)" GitHub issue:

Stebalien/term#93

I think a good starting point for a policy is, unlike other RustSec advisories, having package maintainers self-file these to announce to the community that the crate is unmaintained. I think this could have a secondary effect of helping maintainers in this position to find new maintainers. New maintainers can then remove the unmaintained.toml once they take ownership, and by doing so, the RustSec database gets a bonus added effect of becoming a sort of visibility point / audit log of crate ownership transfer in these cases.

I've just noticed there's
https://crates.io/crates/alt_serde_derive
which points to the same repo as
https://crates.io/crates/serde_derive
It pops up in autocomplete

Any information about this package? Is it secure?

Dependabot couldn't find a Cargo.toml for this project.

Dependabot requires a Cargo.toml to evaluate your project's current Rust dependencies. It had expected to find one at the path: /Cargo.toml.

If this isn't a Rust project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

Right now this project is assigning its own unique identifiers to vulnerabilities. However, it would be nice if we could switch to Distributed Weakness Filing for this purposes so we have a more standard way of identifying them (cc @kurtseifried).

Were this to happen, we would replace the existing RUSTSEC-... identifiers with DWF-... identifiers.

I've noticed potentially exploitable security vulnerabilities in the following crates[0], which can be triggered by users of these libraries without writing unsafe code.

I'm filing an issue rather than a PR since I don't know that I have time to see this through to it's conclusion, especially since multiple crates and several functions are involved. The FAQ indicates that this is okay.

pancurses

The crate https://crates.io/crates/pancurses exposes the functions Window::printw and Window::mvprintw as safe functions (I think this is all of them, but could be wrong), despite these passing an arbitrary rust str to into C code which expects to receive a printf-style format string. This can lead to a format string vulnerability.

I filed ihalila/pancurses#66 about this, shortly before filing this issue.

ncurses

The crate https://crates.io/crates/ncurses exposes the functions printw, mvprintw, and mvwprintw as safe functions, which have the same issues described above.

In jeaye/ncurses-rs#172 I raised this issue about printw (but missed that it wasn't just printw), which lead to that functions deprecation[1]. When writing this issue for the advisory-db, I noticed the existence of the other two functions. I don't see any other functions accepting format strings (the scanw functions, mercifully, are not exposed).

Additionally, while filing this bug, I noticed the following additional vulnerabilities or memory safety issues (I haven't filed issues in the ncurses crate's repository about these):

• instr is exposed, which has a buffer overflow (the curses instr function is somewhat similar to the gets function from the C stdlib, in that writes as much text that it wants into a lengthless buffer pointer).

  • EDIT: I've noticed that mvwinstr has the same problem, just not as directly.

• Several functions (1, 2, 3) write data from the terminal directly into a String's underlying buffer, when the data may not be valid UTF-8. I don't know if this can be exploited, but it's a memory safety issue nonetheless. Hopefully the members of this repository have some intuition as to the exploitability of this sort of problem.

• I have not done a very thorough look, these are just the most obvious problems to me. Ideally, someone more familiar with the curses library's API would look further.

[0]: For total clarity, I didn't look at any others. It seems plausible to me that other Rust curses libs have similar mistakes, since it's a very hard API to use safely. That said, I think these are the most popular ones (not that that makes things any better).

[1]: I don't really feel that deprecation is sufficient, as the function is still present (and not unsafe). Transitive dependency deprecations aren't reported, so rust code consuming this crate transitively could still be at risk. However, if the members of this repository disagree, then one fewer of the ncurses crates functions are problematic in the current release.

According to a private email, for the time being he's not working on the project anymore.

The github repo is read-only now.

https://github.com/steffengy/tiberius

I found that both rust-argon2 and argonautica do not attempt to implement constant-time comparison for the verification of passwords. Not sure how important that is in this context, but given that the reference implementation does implement it, it seems like a risk.

sru-systems/rust-argon2#21
bcmyers/argonautica#19

After discussing the alternatives to spin-rs in rust-osdev/linked-list-allocator#22, it turned out that neither of the proposed alternatives (lock_api and conquer-once) were fitting for this use case. This led to the new https://github.com/rust-osdev/spinning_top crate (instantiating lock_api's API).

As far as I can tell, it's still quite new (version 0.1.0 from 2 days ago), but based on previous code and much more lightweight than other alternatives (therefore easier to integrate in no_std contexts for example).

Would it be relevant to add this alternative as well in the advisory?

We would like to use cargo audit --deny-warnings as part of our continuous integration, but there are occasionally advisories which we would like to( temporarily) give a pass on. (In the current case, that is RUSTSEC-2019-0031).

Having a mechanism by which we could filter out, say, RUSTSEC-2019-0031 so that cargo audit would return a success would be extremely helpful.

See rust-lang-nursery/lazy-static.rs#163 for more on the case that is motiving this feature request.

I had this bug report in the form of a PR: djc/askama#138.

Since lack of correct escaping can result in vulnerabilities, I wonder if this should merit an advisory?

Is there a test package with a test advisory so that an advisory reporting pipeline can be tested? I'm thinking of something along the lines of the EICAR test virus signature to test a malware detection pipeline.

The advisory would have a unique tag and/or category so that it can be unambiguously identified as a test for which no action needs to be taken. (Or maybe there could be multiple test advisories with different properties but sharing the same unambiguous "this is a test" marker.)

I could use a real package with a real advisory, but I'd be concerned that it would interfere with other dependencies, and it wouldn't be clear that it was just there for a test.

This is a tracking issue for which vulnerabilities have CVEs. We should file a CVE for every vulnerability in our database:

Advisories.toml is the only file in this database directly consumed by cargo audit (via the rustsec-client crate).

I originally added this file after some frustrations with consuming data from the RubySec project this one is largely inspired from. The core idea is having a single file which can be consumed via HTTPS rather than requiring database consumers clone a git repository.

Having tried that approach, I think it makes the workflow a bit more convoluted for contributors (and maintainers!) and ultimately just duplicates information. This database is designed to be consumed via a cargo plugin, and Cargo is already designed around an index that's based on a git repository.

I also think an aspiration of this project should be to be merged into cargo proper. We can imagine a future where security advisories are just part of the crates.io index and can be consumed (and authenticated!) just like any other crate metadata.

To that end, I think it would make sense to move to consuming the advisory database as a git repository, rather than as a static file. This would allow Advisories.toml to (eventually) be deleted, which would simplify the workflows for compiling the advisory database.

The Refactor advisory types: add [affected] and [versions] sections PRto the rustsec crate from August 2019 performed some refactoring of the internal data structures used to store advisories, splitting out separate [affected] and [versions] sections:

Advisory V1 Format

https://github.com/RustSec/rustsec-crate/blob/af751d912/tests/support/example_advisory_v1.toml

# Example of a V1 RustSec advisory
# This uses the legacy `patched_versions` field, which we need to support until
# all users have upgraded to parsers which understand the V2 format

[advisory]
id = "RUSTSEC-2001-2101"
package = "base"
title = "All your base are belong to us"
description = "You have no chance to survive. Make your time."
date = "2001-02-03"
url = "https://www.youtube.com/watch?v=jQE66WA2s-A"
keywords = ["how", "are", "you", "gentlemen"]
aliases = ["CVE-2001-2101"]
cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
patched_versions = [">= 1.2.3"]

[affected]
arch = ["x86"]
os = ["windows"]
functions = { "base::belongs::All" = ["< 1.2.3"] }

Advisory V2 Format

https://github.com/RustSec/rustsec-crate/blob/af751d912/tests/support/example_advisory_v2.toml

# Example of a V2 RustSec advisory
# This uses the new `[versions]` subsection, which we'd eventually like to
# switch to, but we need to make sure all users have a `cargo-audit` which
# supports the new format first.

[advisory]
id = "RUSTSEC-2001-2101"
package = "base"
title = "All your base are belong to us"
description = "You have no chance to survive. Make your time."
date = "2001-02-03"
url = "https://www.youtube.com/watch?v=jQE66WA2s-A"
keywords = ["how", "are", "you", "gentlemen"]
aliases = ["CVE-2001-2101"]
cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"

[versions]
patched = [">= 1.2.3"]

[affected]
arch = ["x86"]
os = ["windows"]
functions = { "base::belongs::All" = ["< 1.2.3"] }

Support

The V2 advisory format shipped in September 23rd, 2019 and is supported by:

• rustsec crate >= v0.13 (current release: 0.17)
• cargo-audit >= 0.9 (current release: 0.11)

Transition Plan

The plan is to convert all advisories to the new V2 format on March 1st, 2020.

After transitioning to the V2 format, all versions of these crates (and third party tools directly parsing advisories) will cease to work due to parse errors for the latest_versions field.

Unfortunately, there was no way in these releases to signal that we are retiring earlier releases of cargo-audit and the rustsec crate (new versions check the RustSec Advisory DB for vulnerabilities filed against themselves and will allow us to display warning messages for obsolete versions), so this will be a breaking change that will force people to upgrade.

After making the change, support for the V1 format will be removed from future versions of the rustsec crate and Cargo audit.

Hopefully this is the only breaking change we'll make to the advisory format in the foreseeable future.

I noticed that you're signing commits with your PGP key, but unless I missed something, I don't think the client actually verifies the signatures.

Since this is a security related repository, I don't think it would be a bad idea to include a PGP signature alongside the Advisories.toml file. Maybe a detached ascii-armored file to preserve backwards compatibility.

Here is a buffer overflow in libc: rust-lang/libc#1501

However, it is exceedingly unlikely that anyone would actually write code that actually makes it exploitable, i.e. manipulates the len in that struct based on an attacker-controlled value.

libc is a transitive dependency of everything ever, so if we file an advisory we would spam people and cause a lot of churn for an issue that's unlikely to be triggered in practice. On the other hand, this leaves a potential vulnerability unreported. Thoughts?

Right now picking the next available vulnerability ID is a manual process. This resulted in the duplication of an advisory ID:

#110

Some functionality should be added (to this repo?) to automatically assign advisory IDs so conflicts like this do not happen in the future.

PR #268 added a security advisory related to plutonium, a crate that hides unsafe usage.

However, the security advisory does not report a security issue with the crate, or any defect with its intended functionality, but makes a value judgement about whether the crate's intended behavior is good.

Security advisories are not for "crates we don't like", they're for conveying information about defects in intended behavior.

Unfortunately I don't care about this enough to fill out a proper advisory, but since I looked into it enough to find the UB, here's a few miri error samples if someone wants to finish it off:

fn main() {
    dbg!(flatbuffers::read_scalar::<u16>(&[0u8, 5u8]));
}

error: Undefined Behavior: accessing memory with alignment 1, but alignment 2 is required

(I manually inspected the source code to verify the library doesn't check the alignment itself)

#[repr(u8)]
#[derive(Eq, PartialEq, Clone, Copy, Debug)]
pub enum Color {
    Red
}

impl flatbuffers::EndianScalar for Color {
  fn to_little_endian(self) -> Self {
      self
  }
  fn from_little_endian(self) -> Self {
      self
  }
}

fn main() {
    dbg!(flatbuffers::read_scalar::<Color>(&[5u8]));
}

error: Undefined Behavior: type validation failed: encountered 5, but expected a valid enum discriminant

#[derive(Eq, PartialEq, Clone, Copy, Debug)]
pub enum Void {
}

impl flatbuffers::EndianScalar for Void {
  fn to_little_endian(self) -> Self {
      self
  }
  fn from_little_endian(self) -> Self {
      self
  }
}

fn main() {
    dbg!(flatbuffers::read_scalar::<Void>(&[]));
}

error: Undefined Behavior: type validation failed: encountered a value of uninhabited type Void

While it seems this project is well maintained, I'd feel a lot more comfortable if the cargo audit command could emit a warning if the advisory database stops being updated.

I propose adding a last-maintained or heartbeat field (pending a better name) to the database containing the last date someone from RustSec looked at the file.

Then cargo audit could emit a warning/failure if the database goes some amount of time without being maintained.

Saw this here:

https://www.reddit.com/r/rust/comments/ga7f56/why_dirs_and_directories_repositories_have_been/

The dirs and directories (EDIT: and dirs-sys) crates have been archived on GitHub. No one has been able to figure out why or heard back from the author (edit: someone claims to have received an email from the author and the situation seems bad)

Some stats on current usage:

• dirs
  • downloads: ~15,000/day
  • dependent crates: 523
• directories
  • downloads: ~4,000/day
  • dependent crates: 116
• dirs-sys
  • downloads: ~13,000/day
  • dependent crates: 3

I don't want to be too hasty in filing advisories as that seems rather disruptive and we should probably wait and see what's going on first and if there's some sort of handoff to new owners. But if they're really unmaintained, we should document that.

The home crate is an alternative, but does not provide equivalent functionality (e.g. XDG directories, though it seems the xdg crate might fit the bill there)

This library seems to be completely unsound, see this reddit thread.

The github repository:
https://github.com/da-x/czc-refcell

Edit: This crate doesn't seem to be available on crates.io, but maybe this library could warn against the usage of the github url?

Right now advisories are TOML documents with large amounts of Markdown crammed into the description field. Here are a couple examples:

• RUSTSEC-2019-0023
• CVE-2019-16760

This is suboptimal for a couple reasons:

• Anyone editing Markdown crammed into the description field can't take advantage of their editor's Markdown syntax highlighting or preview features
• Likewise the Markdown is not rendered when viewing advisories on GitHub, which is useful in the PR process to ensure Markdown is well-formatted, but also for anyone browsing the advisory DB's git repo on GitHub
• It makes advisory metadata located below the description field harder to see. As of the move to the new V2 advisory format, this is all version information, which is some of the most important information in advisories.

This issue proposes what is hopefully the last change to the advisory format before freezing it and releasing 1.0 versions of cargo-audit and the rustsec crate: moving to a Markdown advisory format.

Markdown (unofficially) supports the notion of "front matter": typically a YAML document embedded at the beginning of a Markdown file like so:

---
id: CVE-2019-16760
package: cargo
date: 2019-09-30
...
---

The Rust team was recently notified of a security concern when using older
versions of Cargo to build crates which use the package rename feature added in
newer versions of Cargo. If you're using Rust 1.26.0, released on 2018-05-10,
or later you're not affected.

...

This proposal is to migrate advisories from .toml files to .md files which leverage Markdown "front matter" to store advisory metadata.

If this happens, it may make sense to switch the advisory format from TOML to YAML as this is better supported in the Markdown ecosystem (e.g. GitHub will apply syntax highlighting and/or render it as a table).

However, that doesn't necessarily have to be the case: we could also continue to use TOML front matter, which enjoys some support:

---
[advisory]
id = "CVE-2019-16760"
package = "cargo"
date = "2019-09-30"
...
---

The Rust team was recently notified of a security concern when using older
versions of Cargo to build crates which use the package rename feature added in
newer versions of Cargo. If you're using Rust 1.26.0, released on 2018-05-10,
or later you're not affected.

...

This came up via: clap-rs/clap#1569

The specific case is clap is pulling in rust-yaml which has RUSTSEC-2018-0006. They use the vulnerable API, but not in a way that triggers the vulnerability.

I've suggested updating the advisory to note their usage isn't vulnerable, but it'd be nice to be able to specify this programmatically somehow.

Something like:

[unaffected_consumers]
clap = ["2"]

Now that cargo-audit v0.9 is out with support for informational advisories, it would be good to start filing advisories for unmaintained crates.

Previous discussion around this topic:

• #134
• https://internals.rust-lang.org/t/tracking-unmaintained-crates-using-rustsec/10884

Note that for users of older versions of cargo-audit which lack support for informational advisories, these advisories will appear as hard errors. There's not much we can do about that except have people upgrade to a newer cargo-audit release which does.

I'd propose including the version of the last crate release so that in the event unmaintained crates are maintained again and see new releases, we can filter those releases from these advisories automatically. So if the last release of a crate were 0.1.2, add:

unaffected_versions = ["> 0.1.2"]

Ideally we can also add a list of alternative maintained crates to consider so these advisories are actionable. We can always update this list retroactively in the event someone has a new alternative to recommend.

Here are some unmaintained crates that have come up in discussion and some suggested alternatives to recommend:

• chan: recommend crossbeam-channel
• libusb: recommend rusb
• rust-crypto: recommend ring, RustCrypto (org), sodiumoxide
• term: recommend termcolor