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!" )

[desandy]

I would very much like to see this feature. I believe there are many valid use cases. Otherwise, the manner available is to contact the crate maintainers and request a reason.

If you are using a yanked crate and need to make a determination as to its fitness for usage for your project, you are left with no information. Especially if the yanked crate is the latest version. Then should I downgrade, is there a truly compelling reason?

Leaving the ability to yank to the discretion of the developer is wonderful, but, I also believe crates are "yanked" for the wrong reasons. So, simply having a description of why they chose to yank it would be very helpful.

[epage]

Unsure why the proposed solution has the yanked message accessible through an API call to the registry, rather than as part of the Index. My main guess is people will rarely need it and it can keep the size of Index entries smaller.

If we do keep a side-band database for mutable state, some other potential uses

• Unmaintained status (overlaps with rustsec)
• Deprecation status (Changing metadata should be possible without bumping a version crates.io#7146), especially if you can point to a replacement (like rustsec's "unmaintained"
  • Can help with structopt -> clap or rlua -> mlua where they might be considered maintained but they are deprecated
• Broken builds (Remove proc-macro back-compat hack for rental rust#106060) due to compat hacks being removed

A less developed idea is to provide a way to distribute information relevant to #7193.

I talk a little about this database idea in rust-lang/rust#106060 (comment)

[0xPoe]

My main guess is people will rarely need it and it can keep the size of Index entries smaller.

Yes. I think that would be the main reason. But if we set a length limit, it would help us to keep it relatively small.

I will assign this issue to myself. I will bring it to the crates.io team meeting next week and get some initial feedback from the team. (At least check if they have any objections or thoughts before I submit the pre-RFC)

@rustbot claim