Crates.io squatting

#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.

Crates.io incident 2018-10-15
#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.

#42

I think everyone agrees that the ecosystem is better off without squatters, but most people also agree that the time we’d spend setting up an anti-squatting system (3 person-months? just a guess) would be better spent in a different way.

That said, I think it wouldn’t hurt having a better search function on crates.io. I’m not sure what it would look like though, or whether the improvements are worth the time it takes. But I’m sure they would appreciate any volunteers in that area. Could be a fun project!

#43

I understand that exact policy for reclaiming names and enforcement is extra work that the crates-io team may not want to do.

But I’d appreciate if you could at least officially declare squatting as unwanted. The current document gives impression like you don’t care at all, and therefore squatting is condoned.

If you changed the docs to “please don’t squat (we may take action against worst offenders)” it would at least discourage squatting a bit.

Currently we have tragedy of the commons that people who refrain from squatting see good crates taken, and the more squatting is done, the more counter squatting feels necessary.

#44

Personally I think the better alternative is for the tooling (cargo, rustup, etc) to support alternative, curated registries in addition to crates.io.

#45

I wouldn’t think it needs that much of a system. If there is a good feedback loop where people can report bad squatters and they get dealt with, there likely won’t be a lot of people who will continue doing it.

Or, if the current approach is, we’ll wait until the problem goes exponential and then we’ll deal with it, I guess I’m just saying this is already making our lived experiences worse and dealing with it sooner seems like a good idea.

#46

Okay, so it’s basically that nobody wants to be involved enough in management to prevent these types of problems. Which is totally understandable, because they’d be tough decisions at times and would inevitably generate pushback. But yeah, as others have said I worry that crates.io will gradually become a place where you can’t find a free name, and/or the first page of results for many searches will be empty crates. It’s not like this an issue that we made up or is unique to rust: npm for example has recognized the problem (though I have no idea if their countermeasures are successful).

IMO, a policy of “we won’t set a policy until something is obviously egregious” is rather meaningless. For me, claiming 100 crates with the tagline “contact me” but providing fake or missing contact info, and declining to answer when contacted via reddit and github, is egregious. Not for you. Maybe it would take 1000 crates to tip the scales, I dunno. I don’t mean this as a criticism! It’s just a fact that if there is no explicit policy, then it’ll always be easy to move the goalposts a little further and never do anything. But that seems to be the goal anyway, so, fine.

#47

I wouldn’t mind taking on some of this responsibility. It sounds like you might, too? If that’s what it will take to move this issue forward, where do I sign up?

#48

Could we at least get paths or prefix reservation, e.g. so that Carl can reserve any name starting tokio? (If necessary using another separator, e.g. tokio/zmq.)

There are at least two reasons for this:

  • Project authors get free reservation of sub-project names
  • Users get the assurance that any path starting with this prefix belongs to the same project, and isn’t part of some other project entirely, or a trojan