Start requiring a reason for all yanks

[alexcrichton]

@wycats, @nikomatsakis and I have discussed recently the ability to yank a crate with a reason, and then whenever that yanked crate is compiled locally it will present the reason as a warning.

The intended use cases for this would be:

• When a crate is fixed because it will be broken in the next version of the compiler (e.g. a soundness fix or bug fix) then the previous versions can be yanked and nudge users forward.
• If a crate is fixed for a security reason, the old versions can be yanked and the new version can be suggested
• If a crate is renamed (or perhaps deprecated) to another then the yank message can indicate what to do in that situation.

Technically, I believe this should be implemented through:

1. Update crates.io to accept an optional message for yanks. Store it in the database.
2. Update cargo yank to require a message indicating why the crate is being yanked.
3. Change the logic for when a yanked crate is compiled to something like:
   • Use whatever state the registry is currently in, do not update it.
   • Only issue a warning if the crate is compiled, not if it is "fresh" (e.g. has already been compiled).
   • When compilation starts, fire off an asynchronous HTTP request to crates.io to fetch the yank message.
   • Print out the warning whenever the HTTP request finishes or block the build finishing on these HTTP requests to return.
   • Ignore any errors that happen fetching the yank message, they should not fail the build.

I think this should suffice as an "opportunistic nudge" for these situations where possible, although it's certainly no form of ironclad guarantee.

Thoughts @wycats, @nikomatsakis?

[Mark-Simulacrum]

If we can standardize the yank text to a small list we could store it in the index and avoid the HTTP overhead for the common case.

[kornelski]

For the yank of futures 0.2 something like "please use futures-preview instead" would be a useful yank message. Small list of predefined messages wouldn't cover it, unless you allowed parametrized messages, but that might be too much complexity for little gain.
If yank messages have a length limit (e.g. 80 chars?) putting them in the index shouldn't be too bad.

[tarcieri]

Note: there's some discussion of this issue in the context of this thread: https://internals.rust-lang.org/t/pre-rfc-reviving-security-advisories-in-crates-io-rfc-pr-1752/9017/11?u=bascule

Namely that if the "yank message" that gets persisted to the crates.io index can be something like a structured TOML file, a mechanism like this could potentially be used for storing RustSec security advisories in the crates.io index.

However, for that purpose, it would be helpful if the "yank message" could span yanking multiple releases of the same crate.

[DevQps]

I think this would be a great idea. Especially to have some kind of categories signalling why it was yanked together with a more explanatory description. I do however wonder if some authors that just want to quickly yank something will not choose "bug" instead of "security" for example. Maybe an interactive version with a question like: "Does this version expose vulnerabilities?" or something like that.