[pre-RFC] Security advisories as part of crates.io metadata

[untitaker]

@alexcrichton

For example is the motivation to weed out vulnerable crates in the ecosystem ASAP, or is it to primarily just notify developers?

Notification is the means, and weeding out vulnerable crates is the goal/motivation. I've updated the section here: Update motivation · untitaker/rfcs@5a06156 · GitHub

@alexcrichton

I'd recommend just requiring --vers. I think it's easier to understand and I'd prefer to not have subtle differences between cargo yank and cargo advisory. I think it'd be fine to just run the command once per version as well, in theory this is something that's called very rarely.

The idea behind that behavior is: Better mark too many crates as vulnerable than too few. I imagine that enumerating every single concrete version that has been vulnerable to be either tedious or error-prone, or both (i.e. I could imaging to forget a specific bugfix release in my enumeration because I forgot that it existed).

The workflow I imagined is:

• Run cargo advisory without any args.
• Edit out the versions that are not affected in the advisory file and submit
• Release new versions that are not vulnerable.

@alexcrichton

Cargo currently doesn't do this, and it's a tricky thing to do across platforms, so perhaps an alternative strategy could be taken?

What about a hybrid? Try to use $EDITOR if it exists (don't fiddle around much with fallbacks such as trying a set of common editor names like it is sometimes done), dump a file if it doesn't.

I don't know how the situation looks under Windows, but under POSIX it appears fairly easy once you've found an appropriate editor command. Terminal settings e.g. are supposed to be restored by the editor.

@alexcrichton

My recommendation would be that if these are optional keys they don't need to be included at all, e.g. omission is allowed.

Here we go: Allow optional keys to be absent · untitaker/rfcs@fa78731 · GitHub

@alexcrichton

Another thought of mine, can you add two advisory reports to a version of a crate? I'd argue that this should be allowed. For example a low-risk advisory could be issued but then later a more serious advisory could be added which should be messaged out again.

This has been proposed at [pre-RFC] Security advisories as part of crates.io metadata - #6 by troplin

@alexcrichton

To me this I think will be the most contentious part of the RFC. I personally would find this behavior a non-starter, for example, as it would drastically change the ergonomics of Cargo in my opinion. In the few times I've used npm I'm constantly getting deprecation warnings about packages I've never heard of. Not only do I not know how to fix the issue but it's also not always my problem (some upstream maintainer may need to update to a new major version).

I feel like those situations are not comparable as deprecations are much more common (by orders of magnitude!) than security advisories. I simply don't expect advisories to be so common such that developers would be conditioned to ignore them.

I would agree that the "regardless of whether this package is already compiled, downloaded, ..." part is too disruptive though.

@alexcrichton

I would personally also find this as a bit too harsh and go against my personal goal of "Cargo never breaks your build". I feel that with the right messaging strategy we won't need a restriction like this.

@bascule suggested to create an option that makes warnings errors instead. Is that more acceptable? Note my follow-up questions in that thread for which I haven't found a good answer:

@untitaker

Where would this option be? Something like #[deny(security_advisories)] or within Cargo.toml? Or just as a CLI option? I suspect that the former isn't doable since that sort of metadata is not available anymore at compile time.

---

@alexcrichton

I feel like this is on the right track, and I like the idea that cargo publish has stricter requirements than other commands (as it's so much more rarely called). I feel like it may be a bit too harsh, though, to reject a publish if any vulnerable version matches.

I mean "any vulnerable version that matches the version requirements", see also [pre-RFC] Security advisories as part of crates.io metadata - #10 by lifthrasiir

@alexcrichton

I also feel that allow-vulnerablein Cargo.toml is perhaps a little heavyweight for this use case, but maybe a flag doesn't always suffice?

I don't know what you mean by this. Are you saying that allow-vulnerable should affect behavior of publish? This is already my intention.