A crate version is yanked from crates.io after a bad release — what does yanking promise, and what does it not do?

## What a yank is A yank marks a published version as no longer eligible to be selected by dependency resolution, while leaving the version itself in place. crates.io calls it yank; PyPI has the same idea for a release or a file. It is deliberately a middle setting between "attach a warning" and "take it away", and it is reversible — un-yanking restores eligibility. The promise is narrow and worth stating precisely: **from now on, a resolution that is free to choose will not choose this version.** That is it. Every other thing you might hope a withdrawal does, it does not do. ## Who is actually protected Only people who have not adopted the version yet. - A project that pins the exact version in a lockfile keeps resolving it and keeps building. This is not a bug; the guarantee that a lockfile keeps producing the same build is worth more than your ability to interrupt it, and breaking it would turn your bad release into an outage for everyone downstream. - The files stay downloadable at the same checksum. Anyone with the exact version can still fetch it — including an attacker who wants a copy of what you published. - Mirrors, internal caching proxies and vendored copies are unaffected. They hold their own bytes and generally have no notion of an upstream yank at all. - Anything already built — a container image, a compiled binary, a deployed service — contains the code and is not touched by a registry flag. - Nobody is notified. There is no push to dependent maintainers. So an hour after the yank, the population still running the bad code is *identical* to the population before it. The exposure has been capped, not reduced. ## Preventive, not remedial — and why that framing matters It helps to sort your options by which direction in time they act: | Control | Acts on | Effect | |---|---|---| | Yank | future resolutions | new adopters skip the version | | Advisory for the affected range | current consumers | scanners flag it, bots open updates | | Fixed replacement version | current consumers | gives them somewhere to go | | Deletion | future downloads of any kind | breaks pinned builds and rebuilds | An incident response that consists only of a yank has covered exactly one column. The complete reflex is: publish the fix first so there is a destination, yank the bad version so nobody new lands on it, and publish an advisory keyed to the affected version range so the people already on it are told by their own tooling rather than by luck. ## Why yank rather than delete Deletion looks stronger and mostly is not. It does not reach any of the copies listed above, so it does not contain anything that was in the artifact. What it *does* reliably do is break every pinned build and every rebuild that references the version — including, awkwardly, a rollback to a known-good state that happens to include it in its dependency graph. That is why registries push hard toward the reversible flag and fence deletion behind narrow policy, and why some registries offer no deletion at all. Deletion earns its place in one situation: when the artifact's continued availability is itself the hazard. A package containing malicious code or a live credential is not something you want strangers able to fetch on demand, even though removing it will not undo the copies already made. ## Reversibility, and the one place it misleads Yank being reversible is a feature — a maintainer who yanks a release on a false alarm can undo it in seconds. But do not let the reversibility of the flag suggest reversibility of the publication. Anything that was ever public should be assumed permanently public: it was fetched, mirrored, indexed and archived within minutes. If the reason for the yank is that the version carried a secret or a backdoor, the yank is bookkeeping and the real work is elsewhere — revoking the credential, or getting the affected range in front of every consumer's scanner. ## How to answer this in an interview State the promise in one sentence, then enumerate who is *not* covered — pinned lockfiles, caches and mirrors, prebuilt images, and everyone who is simply never notified. Finish with the pairing: a yank is one third of the response, alongside a fixed version and an advisory. Candidates who describe a yank as "pulling the version" and stop there are describing a recall that does not exist.