cargo / crates.io is not immutable - potential risk of left-pad incident

[fschutt]

This is an issue that I'm a bit concerned about: When yanking a crate, cargo does not check if that crate is dependent upon by other crates. Therefore, a left-pad incident can currently happen. If someone would decide to yank libc right now, for example, all hell would break loose.

Example: https://crates.io/crates/libfoo-test

Here we have libfoo, which depends on libbaz version 0.1.0. I was able to yank libbaz 0.1.0, thereby breaking libfoo in the process. What you have to do is to publish a new version of libbaz, then yank the (version - 1) crate. For some reason, cargo neither does semver-checks (it could, for example, see that version 0.1.0 and 0.2.0 are identical) nor does it allow libfoo access to libbaz (in a "you know my sha1, so I'll give you access, even though the crate is yanked" way).

If you try to depend on libfoo now, all you get is:

    Updating registry `https://github.com/rust-lang/crates.io-index`
error: no matching version `^0.1.0` found for package `libbaz-test`
location searched: registry `https://github.com/rust-lang/crates.io-index`
versions found: 0.2.0
required by package `libfoo-test v0.1.0`
    ... which is depended on by `dependency-test v0.1.0 (file:///home/felix/Development/dependency-test)`

This is dangerous because now the maintainer of libfoo has to be notified to manually update his package to upgrade to libbaz 0.2.0. If libbaz has lots of dependents, this can break a lot of builds. Yes, the maintainer can upgrade to the new version, but the damage is done at first. This violates the "immutability" of cargo - once a package (in this case libfo) is uploaded, it should always build. Is this the intentional design? If yes, why?

[sfackler]

nor does it allow libfoo access to libbaz (in a "you know my sha1, so I'll give you access, even though the crate is yanked" way)

It does allow this. An existing Cargo.lock will still be able to use a yanked version.

[matklad]

Yep, as @sfackler says, cargo does not really suffers from left-pad problem, because yank does not remove code, and, if you have Cargo.lock around, you still will be able to use the yanked version.

The relevant docs are here: https://doc.rust-lang.org/cargo/reference/publishing.html#managing-a-cratesio-based-crate

[fschutt]

This just broke my code yet again. The problem is that libraries do not submit their lock files to crates.io because cargo puts them in the gitignore by default. dwrote decided to unpublish itself while I was asleep, and now I got a report that someone can't install my library or run any examples.

So if you want to solve this problem, the don't put the Cargo.lock file into the gitignore by default. Otherwise, the next left-pad is just waiting to happen. Get a lot of dependents, don't submit the lock file, unpublish a dependency and boom, "can't fetch dependencies for X because Y is yanked". Just like it happened now with dwrote, however, dwrote doesn't have any major dependents, so it didn't break a lot.

But don't just say "it doesn't happen because of lock files" - yeah right, because no library right now submits their lock file, because they assume it isn't necessary! And 90% of the things on crates.io are libraries, not binaries. What if I want to install a crate to run an example? Or I just added it to my Cargo.toml file so I don't have the hash yet... now I can't use it because the maintainer didn't submit the lock file because that is turned off by default.

[Eh2406]

cc #5967

[fschutt]

Well, the real "problem" I have is that if there is a dependency that has a lock file, the cargo / crates.io seems to ignore that lock file. For example, if I submit a library to crates.io with a Cargo.lock in it, then I'd expect cargo to recognize that and use the hashes in that lock file, so that even if a dependent crate gets yanked, my crate still works.