How would we handle a cargo left-pad incident?

[larsbergstrom]

Earlier this week, the npm ecosystem got dropped on its head by the removal of left-pad from the main package repository, as fallout in a legal incident the author had with an otherwise unrelated package. The question I'd like to address in this issue is: what's our plan of action if servo gets left-pad'd? (and lest you think this is purely academic, there are crates like num_cpus that have a similar complexity & risk profile).

So, assume Servo has some dependencies on crates B_1...B_n, each of which depend on to_be_unpublished.

I think the long-term answer is pretty clear: B_1...B_n each update to a new fork of to_be_unpublished, rev their semver number, and publish to crates.io. The only wrinkle here is that if any of them transitively depend upon each other and to_be_unpublished is part of their public API, then they will have to make a breaking semver change and updates and publishes to crates.io will have to proceed in reverse topological order of the dependency graph. We deal with this scenario regularly in Servo when there's a breaking change deep in the dependency graph, and it's painful and slow (particularly if one of the B_i is undermaintained) but not unusual.

The bigger questions in my mind are:

1. What do we do about reproducibility of old builds? If this crate has been unpublished from crates.io, bisecting just got broken.

Two alternatives used today are having our own internal mirror of crates.io that never unpublishes or vendoring copies of the entire dependency graph into a VCS system that is intended to be bisectable.

2. What do we do in the immediate term when this removal drops the CI for everything in the dependency chain up to Servo on the floor and prevents us from landing any fixes until the "long-term answer" above is completed?

Top-level overrides pointed at the fork seem like the cleanest solution, though every single project in the dependency chain down to to_be_unpublished needs to make the addition. Assuming this lands, of course :-)

Otherwise, all I can really think of is using a .cargo/config paths override, which also would require introducing a git submodule. While Servo's toplevel has some wrapper scripts (mach) that handle dealing with submodules, most of the Rust/Cargo ecosystem probably will not.

This is obviously not incredibly urgent, but who knows when this will hit the Cargo ecosystem? Obviously, left-pad itself can't happen (only Alex can unpublish a crate, and AFAIK the policy is basically legal-reasons-only), but if somebody made godzilla-pad, Alex will definitely get an e-mail from TOHO :-)

cc @alexcrichton @wycats

[Manishearth]

To be clear, we only have an issue if a major crate is unpublished by Alex for legal reasons. Yanking of a major crate will cause some speed bumps, but not any major issues.

I think in this case crates.io should create a copy of the crate with an acceptable name, and "legacy redirect" it. This works the same way as yanking does: All existing published dependencies are allowed to depend on this and will get appropriately redirected. New publishes are forced to use the new name.

This seems like it would be legal, but I don't speak trademark law.

[larsbergstrom]

@Manishearth I think this would definitely address unpublishes that occur for trademark violation reasons.

I'm still a little worried about it if the unpublish was due to licensing or copyright issues in the code, where the code itself has to be removed. Even if it's a cleanroom implementation that meets 100% of the spec/tests, we may have broken bisection and reproducibility of builds.

[alexcrichton]

Thanks for the cc @larsbergstrom! I was asking @steveklabnik on IRC for some clarification on what happened with NPM, and the sequence of events looked like this:

1. There was an npm user who had a package, kik
2. An IM company, kik, trademarks 'kik'
3. One of their employees of kik wrote a letter to npm about this package (from the npm user)
4. npm contacted the original author to change the name, they said no, and then npm gave the package to the company
5. The original npm author at this point decided to delete all their packages
6. One of the packages, left-pad, is a dependency of many packages in the npm ecosystem

So with this in mind, it seems like there was very little legal action involved here, and there was also no legal action against a core dependency of the ecosystem. Authors on crates.io cannot ever delete the source of a package. Crates can be yanked, but that only means new dependencies cannot be formed, not that the source code is deleted. I do have the ability to delete packages, but only in the sense that I have the keys to the database and S3 buckets.

In terms of what happens if legal action happens against some crate (e.g. rustc-serialize), I don't have a great answer for you there unfortunately, and I suspect it would depend a lot on the details of the situation at hand.

Hope that clears things up!

[Manishearth]

then npm gave the package to the company

Wait, is that right? I thought npm just transfered ownership to themselves?

Giving ownership of the package to the third party is a big no-no with security implications. We should never do something like that.

[steveklabnik]

I thought npm just transfered ownership to themselves?

There was a lot of confusion around this, but yes, they transferred the package to the company.

[asajeffrey]

The case that worries me is if a copyright claim is made on code we depend on. For example, Alice uploads a crate that we depend on, but then a few years later Alice's then-employer points out that actually any code Alice wrote during her employment was owned by them, and please can they have it back.

Part of the reason this case worries me is there really is not much we can do about it, other than check LICENSE files and hope that people who are asserting copyright are doing so correctly.

[frewsxcv]

This might be tangential, but here's the official response from npm, inc. regarding their dilemma:

http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm