Name squatting on the crates.io

Hello, rustaceans. I've noticed squatters on the crates.io - they are taking a crate name so that no one else can use it and, most likely, will ask for money to release it for you, - the same thing which is done in the web for domains. Just one I've noticed: https://crates.io/crates/keyboard
The guy there says "contact me if you need this name".

I propose adding a button to the crates.io for reporting such crates and releasing those after a review. Like a post-moderation for the crates.

Dealing with squatting is something that's been debated a lot. For example on the Rust internals forum: https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302

1 Like

Thanks. That's unfortunate that we can't deal with this. Even I feel a bit of a squatter - I am using the urlshortener name for a client library which performs requests to certain online apis for shortening a url. But the name urlshortener is quite broad and can mean a server, a client, both, and... I feel not well knowing I took it without prior having thought enough of it. But seeing real squatting upsets me. It is like a dog of your neighbour comes to shit in your garden.

1 Like

It's a known issue with any sort of centralised package manager. There are a couple ways you can try to deal with it (e.g. moderation or namespaces), but introduce their own problems in turn and there's no one obvious solution.

It's probably one of those tricky unsolveable problems. Go tried to solve it by using the repo URL as an import path but also ran into problems around versioning and discovery, and have introduced a "checksum database" which is kinda-sorta like a central package repository.

I'll admit that I also get mildly annoyed when I see someone squatting a name I want with no uploaded content or an email address to contact them, but it just means you need to be a bit creative (e.g. tokio for an async IO framework) or use a qualified name (e.g. mdbook-linkcheck as the linkchecking plugin for mdbook).

This seems like a serious problem that Rust needs to head off sooner rather than later. And I do not think the issue is with user behavior. There are many reasons why someone might upload something to crates dot io and then leave it abandoned. “Name squatting” is only one of them.

Something like GitHubs username/reponame should be introduced throughout the package management system, as well as a name disambiguation mechanism (I’m new, maybe name disambiguation is already possible).

So Cargo.toml should become, in my opinion:

crateiosuser/nicename = 0.1.0

Instead of

tortuousbadnamesthatkeepgettingworse = 0.1.0

1 Like

Personally, I'm all for namespaces. I've learnt to trust Apache libs in Java's word, similarly I can tolerate any spring-* thingy. After a while, I just recognize their quality.

I'll just reiterate that all of these ideas (including namespacing) have been discussed before at great length. On my link above Yato links to even more discussions on the matter, and that's far from a list of all the conversations ever had.

If you want to try to move these types of proposals forward you have to address the issues that have been brought up previously otherwise we're doomed to keep going round in circles.

Almost everybody agrees that name squatting is bad. The problem is finding the best way to address that and doing so with the resources Rust has and without frustrating one section of the community or another.

Example of the issues with namespacing are: How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute? What do we do about all the currently un-namespaced crates? How would Rust (the language) understand namespaces? How would cargo work with them?

Someone needs to be able to answer all these questions and more, while getting consensus from the community and those involved in implementing it and moderating crates.io.

I'm not trying to scare anyone off from making proposals. Namespacing is a good idea! And there may well be good solutions to the problems. But all previous discussions on this issue haven't been able to find a way forward. If you want to change that you unfortunately have to do a lot of reading up and work with people involved to find solutions.

5 Likes

It doesn't have to be either or.

Keep the current wild west, but also also allow moderated namespaces (something for the Rust Foundation, when it comes into being, to manage).

Or hey, here's an idea: Support public key namespaces.
My public key is uploaded. Crates.io sends me a challenge. I sign it with my private key, and return the response. Now it knows I hold the private key. My public key is hashed. This hash is my namespace. It'll be long an annoying, but there will be no squatting.

2 Likes

And if you lose a key? Then what?

Instead of using your public key as part of the namespace, you can use a Decentralized Identifier (DID). There is an associated document that provides the public key used for the DID, and there are procedures for replacing the keys.

1 Like

How do other PKI systems handle that situation?

There are different mechanisms for peer to peer and certificate authority systems, but that's not relevant to the question. The issue here is that the proposal uses the public key as part of the crate's name. DIDs were introduced in part so you could change the controlling key without changing the corresponding name.

1 Like

Oh, I'm very well aware (due to both personal interest and dayjob). I was asking a rhetorical question. The problem of losing one's key is as old as PKI; I just thought it was weird to bring it up in 2020 since it has been a well-known problem for literally decades.

What I originally intended was simply for people to take a step outside of the "choose namespace" mind-set, because I fear that will essentially always lead to conflicts. One suggestion is to look at generated names instead. A system in which no one gets to choose their namespace is annoying, but fair. Hashing a public key is just one way of achieving that.

Given the limited people and finances any hypothetical Rust Foundation will have, and the large number of responsibilities a Rust Foundation could have that would be higher priority than moderating namespaces, I think it's highly unlikely this would happen.

cargo-crev is an existing community-driven project I would encourage you to invest in if you're interested in having code reviewed by trusted peers (which is what I'm assuming you mean when you say "moderated namespaces").

3 Likes