Allow dependencies to lock to yanked libraries if no unyanked versions are available.

[Lymia]

Yanking a crate can break unrelated crates that are published on crates.io that depend on it, especially if it uses =1.0.0 dependencies or similar. While binaries can rely Cargo.lock, libraries do not have a similar mechanism.

e.g. if foo=1.0.0 depends on bar>=0.0.1, but bar=0.0.1 is yanked in favor of bar=0.1.0, this effectively yanks foo, because any attempts to build it without a preexisting lock file will result in bar not being resolved for foo. Therefore, if bar was a common dependency, this has the potential to effectively yank a large portion of the crates.io ecosystem until those dependencies are updated.

Allowing dependencies to lock yanked versions if there are no unyanked versions it's compatible with would cover many of the use cases of #4225 and make the crates.io ecosystem more resilient against left-pad style issues.

I understand that yanking is meant for malicious releases and serious security bugs. However I find it equally problematic that someone who owns a dependency of a crate can effectively also yank all their reverse dependencies, so I feel that something like this definitely warrants discussion.

[jonas-schievink]

Yeah this would be nice. We've had our production build break once, because all semver-compatible versions of a dependency were yanked. Granted, we should've checked in the Cargo.lock since this is a binary, but this could just as well happen when running CI for a library crate (where Cargo.lock is recreated on each build).

[briansmith]

I understand that yanking is meant for malicious releases and serious security bugs. However I find it equally problematic that someone who owns a dependency of a crate can effectively also yank all their reverse dependencies, so I feel that something like this definitely warrants discussion.

As somebody who wishes to yank older versions of my crates to make it clear that those older versions are unsupported and may or may not have serious security problems, I agree that this is an important feature. It's not reasonable for a crate author like myself to be expected to keep track, in perpetuity, of all the potential security issues in all old versions of a crate. In fact, I don't think it's reasonable to expect us to even keep track of security issues in any old version of the crate. This means that we need to be able to yank older versions on the presumption that they might be dangerous but probably aren't, because that's better than risking leaving a dangerous version published and unyanked.

[Stebalien]

This just hit several rust crates due to ferrilab/funty#7. Unfortunately, lockfiles aren't sufficient if you need to release a tree of inter-dependent libraries.

[epage]

Since this was created, the recommendation around lockfiles has changed, see https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-cargolock-in-version-control

While this acknowledges #4225 as an alternative, I'm going to close this issue in favor of that issue so we can discuss the problem holistically in one place.