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.

[tesuji]

Hi. I would like to see this feature. I yanked two versions of home crate (0.4.1 and 0.4.0)
because they failed to build on Windows.
It would be better if I could inform this to all dependent crates.

[kentfredric]

It might be useful also to have a mechanism to update the yank reasons.

For instance, if a crate is yanked due to a CVE, then the first time its yanked, it would have that CVE.

However, when CVEs are published, they tend to enumerate 'ranges of affected versions', so its entirely feasible that one wishes to retroactively document in the yank reason any applicable new CVE's that may apply.

But you can see the direction this is heading. The ultimate desire is to encourage consumers to head in the right direction, but to also provide adequate information to give consumers grounds to make choices. Naturally, if a user sees a CVE, and the CVE vector is remote access, and their product doesn't have any remote access capacity (eg: embedded device without a network peripheral of any description), then they'd be fine with ignoring the CVE if upgrading to avoid the CVE would cause some kind of detriment to what they're doing.

Just as-is, this is all terribly obscure and you need to reach for 3rd party tools to even have a hope of making the right decision, as nothing exists to encourage crate authors to inform their users in a consumable way ( "read the README of every crate in your graph, good luck mate!" )