Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
How would we handle a cargo left-pad incident? #10142
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:
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.
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
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 :-)
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.
@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.
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.
Hope that clears things up!
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.