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

[wycats]

I have a few thoughts here as well.

At a high level, the concerns in this RFC draft are pretty similar to other concerns I've had with yanked packages for other use-cases. Regardless of the disposition of this particular proposal, I'd like to beef up yanking to support more scenarios ergonomically.

Some examples:

• "Yanked because the code won't work in a future version of Rust"
• "Yanked because there is a different package that in the author's opinion supersedes this package"
• "Yanked because this version doesn't work on a particular platform"

These examples share some characteristics with the issues that the security vulnerability scenario is trying to address:

@untitaker

Cargo dosen't allow yanked packages to be used in new packages. In theauthor's opinion, people who know what they're doing should be allowed todepend on vulnerable packages, as they might use the crate in a way thatposes no security threat

This is also true about packages yanked because they will no longer work in the future (which hasn't arrived yet) or doesn't work on a particular platform (maybe you're not using that platform) or because it's superseded (maybe you have a good reason to use the old package anyway).

@untitaker

At the same time it doesn't make sense to depend on packages that don't compile, and currently yanking is primarily used to mark such packages

I think that's a too-limited view of yank, but it does reflect the current set of functionality. I personally would like to expand yank to have more capabilities (I've talked with @alexcrichton about "yank with reason" for ages, and that was one of the motivations).

@untitaker

Cargo doesn't give any advice about further procedure when yanking a package.I think in the context of security vulnerabilities this is very much needed,as few OSS maintainers are exposed to this problem regularly enough to knowwhat they're doing.

I think this is a more general problem with yank, and the reason for wanting to beef it up. Security is a particular kind of reason, that might justify special handling, but yanking because the package won't work in the future also argues for better advice from Cargo.

@untitaker

Lastly, the data exposed via the Crates.io would be a lot less structured.

Which gets to my concrete proposal re: "yank with reason".

I'd like to beef up the reason to include an enum of reasons that Cargo could use to supply useful guidance based on what has happened. I would still want to allow unstructured reasons, but I would also want to try to have the structured enum include the most common reasons, as well as reasons that justify special guidance or handling.

@untitaker

However, at that that point yank is no longer generic (as in a function having type parameters), butsimply a lot of single-purpose commands stuffed into one

Given the number of reasons for wanting to discourage people from using a package, I'd like to avoid an explosion of different top-level commands that represent each scenario. Instead, I'd like to extend the conceptual meaning of "yank" to include many more scenarios.

@untitaker

And the name "yank" wouldn't make sense for crate versions that may still be available

I personally think it's fine to have a "yanked" version that is still available (in fact, all yanked crates work that way to some extent), but I would also be open to another general name like cargo discourage

After thinking about your arguments for security, I also think the yanking semantics might want to be a little bit tweaked, even in terms of today's yank.

• It's already true that if I ask for 1.6 and 1.7 is yanked but 1.8 has been released, you get 1.8.
• It's also already true that if your lockfile asks for 1.7, you get 1.7.
• On the other hand, if you ask for 1.6 and 1.7 was yanked, you get 1.6.
• I believe the only problematic case is if 1.6 was released, 1.7 was yanked, and that is the latest version and you ask for 1.7. I think it makes sense, in that scenario, to allow you to use 1.7, perhaps with some additional annotation (similar to allow_vulnerable).

---

For what it's worth I don't necessarily oppose having a suite of security commands that are effectively sugar for "yank with structured reason", but since there are other kinds of yanks that share characteristics with security vulnerabilities, I'd like to try to beef up the primitive first (or at least, at the same time).