Crates.io squatting


#21

can crate names have dots in them? e.g. soniex2.hexchat-plugin? what’s the length limit? etc?

can crates “provide” a different crate? e.g. could the hypothetical soniex2.hexchat-plugin be a drop-in replacement for hexchat-plugin?


#22

Package names consist of a valid Rust identifier plus hyphens. There is no formal hard limit to package name length (that I am aware of).

The package name is not bound to be the same as the library crate name, but by default the crate’s name is derived from the package name (by replacing hyphens with underscores). For an example (of the by convention namespacing you seem to be hinting at), see piston-gfx_texture.


#23

can we have dots in package names?


#24

The question has been answered:

Package names consist of a valid Rust identifier plus hyphens.

IOW, the answer is no.


#25

can we get the ability to use dots in package names?

(sorry I realize English can be a little ambiguous sometimes)


#26

We will remove any package which is malware, regardless of its name.


#27

How is that determination made? Is there a defined process for that?


#28

You can report any packages you believe to be malware to security@rust-lang.org.


#30

Where can we discuss updates to this policy? It’s obviously become unsustainable as the crates.io community has grown.


#31

I don’t agree that it is obviously unsustainable, or that anything at all has changed significantly since 2015 that would cause us to revise that policy.


#32

Perhaps I should have said “arguably” instead of “obviously”. What has happened (predictably) is people doing land grabs of crate names in bad faith (1, 2, maybe more). I realize that the core team doesn’t consider this squatting because there is no definition of squatting, but it clearly is something. And what’s frustrating is the refusal to acknowledge that it happened or could be a problem in any way. If the core team wants to say “yeah, this is inevitable and here’s why we don’t think it’s an issue”, that would be one thing, but when you say nothing has changed, do you see why that is galling?


#33

It is annoying indeed that swmon has also been squatting, but I don’t think the situation has changed fundamentally since mahkoh's squat. So I don’t see why the situation would have changed.

If you have new arguments or proposals that weren’t mentioned before, then I suppose that this is the place to mention them.


#34

This is the key, I think. Cries that “somebody should do something” are no more useful in moving the conversation forward than ignoring the issue.

I doubt anybody strongly disagrees that this is a potential problem at some point, whether or not we’ve reached it already, but there has obviously already been significant discussion on this problem, and barring either:

  1. A significant change in the problem of ‘squatting’ in its actual effect beyond annoyance, which doesn’t yet seem to be manifest.
  2. A bold new proposal as to how to deal with the problem that merits discussion.

There’s not a whole lot of new ground to tread, is there?


#35

If the core team wants to say “yeah, this is inevitable and here’s why we don’t think it’s an issue”, that would be one thing,

I feel like that was said, in the OP.


#36

I feel like the only thing that would motivate a change in policy is one or more specific examples of cases when crate squatters are unwilling to give up a crate name to a developer who wishes to publish code under that crate.

There’s been several threads on the topic of crate squatting, and in them I can’t recall any instances of a refusal to release a crate. If I’ve missed it, I think it should be resurfaced again for the community to examine.

To loosely borrow a term of United States law, we need someone with “Standing”


#37

I think we certainly will need a policy for crates “expropriation”. Something like this:

  • If someone wants already registered name for their project, they can write a request in which they will be required to show the code which is best published under requested name.
  • Such request can be written for crates which was not updated in 6-12 months.
  • Team which will review such requests will try to contact owner of the crate, at least 3 times over 3 months.
  • If owner explicitly says “no” to the transfer, request will be automatically denied, even if owner does not have any code. No new “expropriation” requests can’t be filled for the crate in question for another 6-12 months.
  • If the team is unable to establish a contact with the owner in 3-6 months, crate will be transferred to requestee if he is still interested in it.

We probably will also need a safety feature to disallow publishing of updates to existing major/minor versions of the crate.

I think this policy is a must-have, especially considering Rust future. Funny names (reqwest) are good and all, but farther we go, the more crates.io will be plagued with dead unsupported crates which use “good” names. And users often don’t bother with researching alternatives and go with the first “working” option, which easily can be outdated, have vulnerabilities, etc. This can be alleviated a bit with Rust Bus, but I don’t think it’s enough.


#38

My guess is that the policy you just described would encourage anyone wanting to take the name from a squatter to just go ahead and come up with a different name for their crate rather than go through such a prolonged and uncertain process. This is probably a GOOD THING™ as it would only be used in truly egregious circumstances.

To paraphrase the character Emil Saing, “I Like It!”


#39

I don’t want you to feel that anyone’s denying that something you could call squatting is happening. Its clear that most - maybe even all - of the crates claimed by these users will never be used for useful projects, and its clear that the names chosen were chosen because they are obvious names for projects. But I say nothing has changed because the policy was made in full awareness that this sort of thing would happen, and the fact that it has happened doesn’t make me feel like we have any reason to revise the policy.

The relevant teams don’t want to be responsible for adjudicating whether a crate name is “squatted” or not. The reality is that many prominent members of the community squat names in advance of uploading them - including myself - and some in fact have many squatted names, similar to these users, but with probably better justification (e.g. Carl Lerche has claimed a lot obvious tokio- names, not all of which I believe he has a project he intends to upload for them). The political impact of having to draw the line is stressful and sinks a lot time.

Its possible that someone will do something so egregiously spammy that we need to reclaim their crates from them. I would really prefer that this not happen, because it will waste a lot of our time and not lead us to revise our policy regarding other users. Wherever the line is at which we start revoking squatted crates, I don’t think any user I’m aware of has reached it, and I don’t see why that would ever change.


#40

I feel like there’s a lot of focus here on the downsides of squatting for people who want to publish a crate (with a squatted name), and not enough focus on people searching crates.io looking for a crate that fulfills their needs. The latter is a much bigger audience, and a very different audience, and I think leaving crates.io a place with lots of useless crates just gives a very bad impression.

I honestly find it very hard to understand the reluctance to deal with obviously bad actors. Yes, making good decisions is hard and sometimes stressful. Why is the responsible team abdicating that responsibility, leaving crates.io demonstrably worse off for several categories of users?


#41

Ooh I like the idea of hiding crates without code.