Is it really a good idea for Cargo to silently choose out-of-date versions of crates to avoid pulling in multiple compatible versions of another crate?

[bascule]

@mtrantalainen

This is a good question. I think the best way forward would be to allow cargo authors to retroactively specify old versions as broken. That way when crate version 0.22.2 is published, it (the version 0.22.2) would include metadata that version 0.22.1 (or any other older version) is broken with a message "Security vulnerability: RUSTSEC-2021-0119".

This is basically what yanking is for, although it'd be nice if authors who are yanking crates could include a reason for yanking, e.g. a security vulnerability

Pre-RFC: Reviving "Security advisories in crates.io" (RFC PR #1752)

Ok, so, after thinking about this for awhile, I have a new proposal. How about the thing @alexcrichton suggested 3 years ago that the core team keeps telling us we should consider? If a crate is fixed for a security reason, the old versions can be yanked and the new version can be suggested Good idea @alexcrichton! So how about this: each cargo yank event has associated metadata, in the form of a TOML file. If we allow this data to be mutable, it can be back…