Support multiple URLs in the URL field

[Qwaz]

The current advisory format only allows a single entry in the URL field, but sometimes it is useful to include multiple URLs in advisories.

Examples:

• RUSTSEC-2019-0034 was an advisory for two bugs, Failing to drop HeaderMap::Drain causes double-free hyperium/http#354 and HeaderMap::Drain can cause data race hyperium/http#355. I included the links in the description section and left the URL field empty, because it only supports a single entry.
• RUSTSEC-2019-0035 used a changelog URL that lists PRs and issue IDs patched in that version, but it would be better to include precise issue numbers that are related to the issue in the advisory itself. For instance, add Miri to CI rust-random/rand#781 mentioned in the changelog is not directly related to the bug.
• RUSTSEC-2019-0009 put use-after-free when growing to the same size servo/rust-smallvec#148 in the URL section, while Using grow to shrink can cause corruption. servo/rust-smallvec#149 is also relevant.

Is it too late to introduce this kind of breaking changes to the advisory format, or can we still do this as part of V3 migration (#414)?

[tarcieri]

I would suggest a non-breaking approach which adds a brand new references section in addition to the current url field.

The references section can be a list/array of URLs, but url still provides the most definitive information about a vulnerability.

[Qwaz]

I like the name references. One question though, what would be the recommendation if there are multiple equally definitive URLs (as in RUSTSEC-2019-0009)? Put one of them in url and the other in references, leave url empty and put both of them in references, or something else?

[tarcieri]

I think it's up to the advisory author to decide. If there's no definitive one, they could all just be references.

[tarcieri]

It seems references is already used for a list of vulnerability IDs, and there's some usage of it in the current advisory DB, unfortunately.

[BlackHoleFox]

Its not as fun as references, but maybe “sources”, as in “information sources”?

It would be great to have multiple, for example, if you wanted to link the issue that has most of the information but also the PR that fixed it, which I bumped into wanting to do earlier.

[tarcieri]

@BlackHoleFox I had a similar thought, but resources

[tarcieri]

Reflecting on this, I'd really like to use references for this, since that's standard nomeclature in other vulnerability databases, but that'd be a breaking change.

One possible way to do it:

• Rename the current references section to related. This is non-breaking.
• Update the database to move all the existing references to related
• After clients have been updated (this may not even be breaking), start introducing URL references

It'd be interesting to experiment and determine if existing clients could parse URLs in the references field as well

[Qwaz]

RUSTSEC-2016-0002, RUSTSEC-2019-0002, and RUSTSEC-2020-0024 seem to be the only advisories that use references field at this point of time.

[tarcieri]

PR to rename references to related: https://github.com/RustSec/rustsec-crate/pull/261

The former is still preserved in the linter.

After that we'll need to rename it in the advisories, and then add support for a new URL-based references field.

[pinkforest]

This works today as:
references = ["https://foo.com", "https://bar.com"]

I've added Doc PR #1354

Closing as Completed