Add flag to allow Cargo to create a lock file that depends on yanked crates

[retep998]

Currently if you have a Cargo.lock that depends on yanked crates you are able to build the project just fine as the yanked crates still exist. However there is currently no way to create a Cargo.lock if the only versions of some dependency that satisfies version constraints are yanked, aside from creating a Cargo.lock by hand which is a really poor solution.

I propose a new flag that is added to Cargo commands capable of creating a Cargo.lock which will allow Cargo to add dependencies on yanked crates if it has no other option.

Inspired by https://users.rust-lang.org/t/crates-io-disable-yanking-crates-that-have-dependant-crates/11492

[carols10cents]

I'm mostly against this because it defeats the whole purpose of yanking (which could have been done because of malicious code or a security problem). I also think this could at least be prototyped in an external tool first, and we could get a better idea of how often this is actually needed and whether this is the solution to the problem that we want to bake into cargo.

Leaving this open for others' thoughts, though.

[pietroalbini]

Having a flag like this (even perma-unstable) would be really nice for Crater: it regenerates lockfiles every run, so if a crate depends on yanked ones it can't be built anymore.

[briansmith]

I'm mostly against this because it defeats the whole purpose of yanking (which could have been done because of malicious code or a security problem)

Consider the ring crate, version 0.12.x. Are there security problems with version 0.12 that are fixed in later versions? Nobody knows! Because nobody knows, it's not reasonable to leave that version un-yanked. But, yanking it breaks lots of stuff, even though that's not the intention.

When I say "Nobody knows!" I mean that! I have completely forgotten what was in ring 0.12.x compared to later versions, and I am the crate author! We can't be expected to keep track of security issues in old versions indefinitely.

[sbditto85]

Speaking of ring 0.12.x i have a bin that uses biscuit 0.0.8 which depends on ring 0.12.x ... because of that i cannot add any other non-related crates (like hex which has no deps) because that would be creating a new lock file. We are currently working on updating deps etc, but it really leaves me high and dry trying to add a quick feature we need. It would be nice to be able to include ring 0.12.x in my cargo.toml file with a flag that says "yeah i know its yanked but I accept any consequences until i can upgrade"

[carols10cents]

@sbditto85 If you had a lockfile containing ring 0.12, you should be able to upgrade unrelated crates without affecting the locked dependency on ring, but there's currently a bug in cargo affecting resolution in a way that breaks this: #6609 A workaround until that gets fixed is to use your VCS to check out the changes to the lockfile having to do with ring and biscuit, and keep the changes to the crates you're adding, like hex.

[birkenfeld]

Another valid use case that came up on Reddit: allowing people to do git bisect.

[dpc]

Another use case: I am writting a fuzzer. I want to temporarily run it against a affected crate version to see if it would catch the problem.

[dtolnay]

Workaround for those landing on this thread needing to do this: I commented the following line:

cargo/src/cargo/sources/registry/mod.rs

Line 790 in 8412d30

&& (!s.is_yanked() || self.yanked_whitelist.contains(&s.package_id()))

then compiled Cargo using cargo build --release, and then was able to generate a working lockfile using /path/to/cargo/target/release/cargo generate-lockfile. Once the yanked crate is in the lockfile, any other Cargo will be able to build it and you no longer need the undermined build.

[Lindenk]

Imo it's insane we need to patch Cargo to build old projects. The notion of yanking packages on crates.io clearly needs revision

Security is secondary to backwards compatibility and working code