-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How would we handle a cargo left-pad incident? #10142
Comments
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. |
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:
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! |
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. |
There was a lot of confusion around this, but yes, they transferred the package to the company. |
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. |
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 |
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
.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
The text was updated successfully, but these errors were encountered: