I think case by case is really the only way it can be done, but it can be augmented by having a reporting function on crates.io that would make it easier for the folks deciding to focus their attention.
People have aired concerns earlier about crates becoming available for reuse: if you depend on some crate and that crate suddenly changes ownership, there’s all kinds of tricky trust issues. Are all the downstream users okay with giving as much trust to the new owner as they did to the previous one? In the end a crate can execute arbitrary code on your machine, so there are big risks here.
At the same time, I do think that shrinking away from trying to fix these situations is not a good long-term strategy. The same person 5 years later might also be less trustworthy for whatever reason; better to hand off their useful crate to some other maintainer who has proved to do good work.
No matter what, the arbitration would likely (1) have to provide transparency on what decisions are made, and roughly on what basis, but (2) must be allowed some leeway; very strict rules can easily be gamed, and that’s a risk, which is why I think actual people deciding together would be the best way forward.
I think forcefully taking ownership of crates in anything more than the most trivial cases will be very contentious, and I’m not in favour of it. We absolutely should not take a package from a person only because that package has <5 active users, the publisher has <20 packages, and the community mistrusts the publisher. Things can break for real people when you un-register a package that’s in use. On top of that, the moderation schemes that are currently being proposed can easily take 1 FTE of continued effort, which is way too much for a small organisation like Mozilla Rust to pay.
And if we pursue a policy of un-registering only trivial cases, then is this committee really worth the effort? Determined people can still get around it. And there might still be boatloads of squatting.
Of course there isn’t so much spam right now. I understand that some people are afraid that there will be an “explosion” in spam or whatever, but this is not a given, and it’s also not something that’s much harder to fix retroactively.
But I’m in favour of proactive non-committee solutions like CAPTCHAs, phone validation and rate limiting. All of those I think will be generally accepted by the community. Perhaps even a fee schedule.
Hi! I stopped following this topic after 20 replies so maybe someone already mentioned this but what if we will use as crate unique identification not only its name but combination of author and crate? The same way as Github and other similar services do.
@HaronK I was thinking the same, but with the original author’s GitHub username. The Cargo.tomlauthor isn’t necessarily unique, and email addresses can change.
AFAIK publishing still requires a GitHub account - assuming other identity providers become supported in the future, that would imply another level of namespacing. So the full logical name would be something like:
We also could introduce crates.io authors. So all currently existing crates won’t have any author but new ones will do. And if in Cargo.toml author is not mentioned then it will look for crate without author.
If you're going to put github.com/username/cratename in the namespaced identifier, you can just as well add https:// to the identifier and use Git URLs instead
Second of all; aren't you just moving the squatting problem over to GitHub? You can register names there just as freely as you can register them on crates.io. Top-level domains have cost, which limits squatters in a way that GitHub accounts don't.
There is a decent amount to think about to be careful with the behavior of Cargo to avoid automatically upgrading to an otherwise compatible version when change of ownership occurs.
Having a public key hosted by the registry has other (solvable) issues to address.
Cargo could handle this by:
Including the appropriate public key signature in the Cargo.lock file; cargo would check that new releases are signed against the key. Otherwise the user would be prompted/warned/etc.
To allow for key rotation for projects which do not change ownership, new public keys can be signed with the old private key. A registry host would prevent new releases being published signed with an old key.
In the case that a key is compromised, crates-io (and self-hosted registries) can prevent uploading new packages signed by the poisoned key.
While I generally like the domain name solution, I think it complicates the story around being able to find crates that are well supported by the community (such as serde, etc) and I think its valuable to at least come up with a story about how this could be improved in the context of domain naming (or similar idea such as pet-naming which was mentioned in a previous name squatting discussion).
