Crates.io squatting


#143

I don’t see a problem here.

Control of the crate changes when the ownership of the domain changes. This is expected and exactly as intended.

Libraries depending on the crate will get a warning that the signatures have changed, and crates.io might even enforce that after a change in ownership a new major version needs to be introduced, so that no one is upgraded silently, even if he/she ignore the signature warning.


#144

Considering the experience from package repositories which have successfully used this approach for more than a decade … this problem just doesn’t exist.

And even if it did, this could be addressed by being able to rename the crate in the Cargo.toml file.


#145

Is it worth making a distinction between “crates.io doesn’t say anything about squatting at all” and “crates.io explicitly allows crate squatting”? It’s my understanding that crates.io doesn’t explicitly allow it, and doesn’t explicitly forbids it. While a serial squatter could make the claim that they have no violated the letter of the crates.io policy, I think this discussion thread shows that the community is very much against it, and so this person would have a hard time arguing that they didn’t expect there to be repercussions.


#146

On Reddit, u/dirtlamb5 pointed out that the user cratesio has grabbed 188 short crate names just today.


#147

I wonder if it is possible this is someone proving a point?


#148

I think what we need more is a policy that ensures a squatted crate is handed over to a person who needs it. Right now the squatter can refuse to do so and there is nothing much anyone can do about it.


#149

One thing in this discussion I’m still not clear on: What is the definitive definition of “Squatting”? I’ve heard a lot of things that boil down to the equivalent of, “I can’t define pornography, but, I know it when I see it.”


#150

Everyone, Crates.io incident 2018-10-15

Thanks.


#151

Editions provide a way to make transitions in certain parts of the language. Would they also provide a way to make transitions elsewhere in the ecosystem? Too late for it to be a Rust 2018 thing, but could each edition provide an implicit namespace on crates.io? E.g., to reduce the problem of "I have some legit dependencies on crate x" but it is no longer maintained—unfortunately the name will have to be taken forever—instead, “For Rust 2021, I’ll need to run a fixup script to change the dependencies to be 2018/x because the name is going to be freed.”

This might be a horrible idea, but it would let us put off supporting / in crate dependencies until the next edition release, and it would also allow people to usually just refer directly to the crate name (e.g., "to do this, you need to install clap" rather than "to do this, you need to install kbknapp/clap") since that kind of communication can come with the implicit connection to the current edition.

We have that kind of partitioning of names of entities in everyday speech when we refer, e.g., to a particular player being on the Bengals (implicitly referring to the current year’s roster) vs a particular player being on the 1987 Bengals.

A review of spammed/squatted crate names would then only have to occur in the run-up to a new edition. (Granted it doesn’t solve the short-term problem of massive spamming, but it provides a cleaner transition point for new crates to take over old crate names.)


#152

This is true of most concepts and not necessarily an argument against policies about squatting. There are fuzzy cases of whether or not something is theft or murder such that we may struggle to produce a formal definition that satisfactorily applies. In those cases determinations are made about the specific case and possibly our definitions of the concepts or regulations are refined, but it’s not a reason to give up having policies or enforcement mechanisms against those acts, or a reason to not believe those acts are thing that exist and can be discussed.

A policy could simply refer to “squatting” and give large leeway in moderation decisions, or it could adopt one of the many definitions offered in this thread such as @kornel’s. Obviously those definitions are not exhaustive, deterministic mechanisms that will unambiguously resolve every possible situation, but they at least identify creating a crate for purposes other than sharing substantive, non-malicious code with community as against the policy of crates.io.

I tend to think the maven-like domain name model is the best long-term path for cargo, but that doesn’t mean easier and more direct policies and mechanisms shouldn’t be put in place sooner.


#153

It is like this indeed. For example, retep998 has over 400 crates and it looks like many of them are placeholders, but they seem to exist for a good reason. I must admit, this would be a good case for namespacing them all under winapi/. But 188 got user deleted (which doubly sucks, because these crates are now really going to be stuck in limbo?)


#154

We’ll have a full report later, but I’d appreciate avoiding speculating until then. Thanks for your patience.


#155

It’s a business model to grab names and sell them back later. It has been done with domains for a long time. http://domainflippingguide.org/buying-and-selling-domains/

Maybe I should register a bunch so I can make $$$ in 10 years time with them…


#156

It’s worth noting that npm forbids squatting

  1. “Squatting” on a package name that you plan to use, but aren’t actually using. Sorry, I don’t care how great the name is, or how perfect a fit it is for the thing that someday might happen. If someone wants to use it today, and you’re just taking up space with an empty tarball, you’re going to be evicted.
  2. Putting empty packages in the registry. Packages must have SOME functionality. It can be silly, but it can’t be nothing. (See also: squatting.)

What’s interesting about it is that they don’t exactly define what squatting is.

  1. Get the author email with npm owner ls <pkgname>
  2. Email the author, CC support
  3. After a few weeks, if there’s no resolution, we’ll sort it out.

Don’t squat on package names. Publish code or move out of the way.

And it seems to work. I haven’t seen reserved crates on the much larger npm. It has reached the point where most trivial names are taken and some of them are dead, but they’re taken by packages, not squatters. And it’s encoraging to know they’re not lost forever and could be revived if someone interested came along.

npm, despite being a company, is not very big. They definitely have much higher package per admin ratio than cratesio, so this is a solvable problem.


[Pre-RFC]: Packages as Namespaces
#157

This seems like an even worse solution. If I have a multi-crate project, without some sort of squatting on future subprojects, I have no guarantee that someone won’t take these. Without some sort of namespacing, à la winapi-*, I am forced to squat all the names that I feel like I want to expand to in the future (see, again, the winapi-* crates).


#158

Yes, this is why I’ve repeatedly argued that name-spacing needs to be part of the solution. That seems to be off-the-table though. My intention is to work on a new replacement for “crates.io” and hope that can gain traction rather than continue to bother the core developers about decisions they’ve already made and have made clear they aren’t interested in revisiting. (Please don’t take this as negative. It is not intended to be. Just an acceptance of what has been communicated.)


#159

One approach would be to have a hierarchy, not necessarily namespaces.

Part of the gruff about namespaces is that it encourages fragmentation. Everybody can have their own version of a crate.

But from all the examples I’ve been reading about, it’s not people wanting their own implementation of a specific word. Instead it’s people wanting a place to put associated crates for a crate they’ve already published. Serde, winapi-*, etc.

So when I say heirarchy, I mean attaching crates as a child of another crate. Pretty similar to namespaces but with less of the downsides mentioned in old explanations of not wanting them .


#160

That is very interesting! I’ll try to whip up a pre-RFC with a similar policy tomorrow if no one beats me to it.


#161

That sounds pretty similar to [Pre-RFC]: Packages as Namespaces

Ping @samsieber, @gbutler as well.


#162

Wow, many thanks, I’ll check it out. I wish I had read though all the new post titles before posting :slight_smile: