Pre-RFC: Formal squatting policy on

I think the issue here is crates using a name but not doing anything with it. IMHO, dealing with crates that are actively malicious or otherwise untrustworthy should be treated as a separate issue from squatting.

The problem here, as I understand it, is only that a name is unusable due to squatting and it can also add noise to search results.


I think there is some overlap, both in terms of the things themselves (malicious activity and squatting) and in terms of their mitigations. For example the @babel/core namespacing style both helps work around squatting, and means that you don't need to allow transfers in crate ownership (just fork the crate and release it with a different prefix), thereby also helping with security.

Just an idea off the top of my head: If you had both namespaced packages and package sets, then you could have package sets with the additional restriction that only one package with a given name (without the prefix) is in the set, and then you wouldn't have to include the prefix when selecting packages from the set.

Could just go for the "perfect" solution of requiring all new crate names to be "<user_public_key_hash_in_base64>/<readable_crate_name>", where submitting requires providing a public key that hashes to the specified hash and signing the submission request with it.

In addition to making squatting no longer a meaningful concept, this also allows Cargo to get packages from untrusted registry servers, since the crate signature verification provides security itself (not against version downgrades, but the version field in Cargo.toml addresses that).

The alternative to @org/package syntax I've seen suggested is a way to claim a myprefix-* or myprefix_* crate namespace, which would work with the existing module system.


Alternatively make packages behave more like namespace so that by publishing foobar only you also get to publish foobar/xyz or another way to combine different levels of packages. That way orgs like amethyst would get a reasonable naming scheme without having to worry about conflicting names or other published packages with that naming scheme.

1 Like

That doesn't solve the issue of squatting crates like swmon is, though.

who cares? all their stuff gets moved to swmon/ and we forget about them.

1 Like

No one seems to have any objections to the three criteria proposed... It all seems to be "why even have rules if people will get around them?". And then bring up completely unrelated issues such as hijacking, as if people can't go buy a random crate name and execute the imagined attack right now.

1 Like

Any policy for forcibly transfering ownership of crates from their current owners has security implications which you are blowing off, much in the same way you were accusing others of blowing off a potential namesquatting policy because it's trivially circumventable. not an excuse for ignoring the security implications of a namesquatting policy. Claiming we should ignore a threat because another threat of similar severity exists is security nihilism.


This squatting issue has gone in circles already, so here's a fast-forward:

  • There is a value in short, memorable and relevant names. If you eliminate squatting by not letting anyone have them, then you haven't solved the problem, you've destroyed the value.

    • There's an infinite number of nonsensical meaningless names (like "nokogiri" or hashes), so using them is a way to around squatters, but that is a loss of value in naming.
    • crates ecosystem is very open-source-centric, so it is possible to cooperate to ensure that the crate with the best name is actually useful, and not a mine to avoid.
  • namespacing moves squatting of crate names to squatting of namespaces. I'll register the "google/" namespace, and we're back to square one.

    • using GitHub user/org names in crate names increases dependence on GitHub and effectively outsources moderation to them. Naming of Rust crates would be governed by entity that doesn't care about Rust's problems.
    • User names don't make good crate names. Is it retep998/winapi or retep989/winapi. Do you really want to make remembering this mandatory for using Rust on Windows?
    • GitHub user and org names can change (only internal ID is stable), and old names become available for registration again. This creates a huge problem when someone changes their name on GitHub.
  • Malware will be removed by crates-io, so that isn't a motivation for anti-squatting policy. Security aspects are a huge can of worms themselves, and much wider than just typosquatting. Many of these things can be done and would be useful regardless of squatting policy.


Small note, “nokogiri” is not a nonsense name; it’s a kind of Japanese saw. Japan is where Ruby originated, and parsing a string is kind of like chopping it up.


One could imagine a system that has

  • a nonsensical name for each crate
  • sensible->nonsensical mapping in each toml
  • a public curated sensible->nonsensical list + a lint/tool to check against it
  • local settings in $HOME folder for which list to check against

Compiler/cargo would use nonsensical names for dependency resolution. Users would always see sensible equivalents from either the curated list or from local overrides. Code would use sensible names from toml.

Re-assigning a sensible curated name would be rare and require a heavy process akin to RFC. It would be possible to quickly replace a mapping with a stop sign in case of malicious code detection.

Curation could be assisted by/augmented by/replaced with information on how many other crates refer to nonsensical name X under sensible name Y. Perhaps some measure of crate popularity/ranking could be taken into account. In any case users should be free to replace this with an alternative mechanism of their choosing.


Personally, I would still be interested in someone taking the time to write an exhaustive analysis and I still question the value of continuing another spitballing/pile-on thread on the subject.


namespacing moves squatting of crate names to squatting of namespaces. I'll register the "google/" namespace, and we're back to square one. [...]

  • [more]
  • [outdated]
  • [claims]

Let me fast-forward you to [Pre-RFC] Domains as namespaces.

You may dislike the solution, but let's not pretend other communities haven't solved this problem for 15 years already.

1 Like

I just re-read most of that thread, but I didn't see any direct responses to any of kornel's namespacing bullet points (and about half of them didn't even get mentioned). Plus, despite having read most of the past threads on namespaces and squatting, I've never gotten the impression that any of these problems are uncontroversially "solved" by other communities, in the sense that there's no debate to be had anymore. It's obvious that other communities have taken other approaches, but there was all sorts of debate not only over whether their decisions were right for them, but also over which of their successes and failures would translate to Rust's ecosystem.

In other words, I don't think the situation is anywhere near simple enough to justify being so dismissive about these objections.

(personally, the arguments that namespaces wouldn't really accomplish much seem solid to me, but for squatting I've never been able to form an opinion either way; there's decent arguments in a million different directions and no clear way of breaking that logjam)


For everyone: please keep in mind my original proposal. Regardless of you preference, namespaces do not currently exist. Squatting does. I put forward three criteria that would need to be met for a crate to be transferred. Please address that and stay with the original topic.


I agree – but as namespacing largely resolves the issue, it's important to correct claims to the contrary.

Nailed it. This is what makes these particular discussions so exhausting:

  • Claims that it's "easy" to solve problem X if you just do Y, and that everything works great for project Z which chose to go in the proposed direction
  • Disregard for:
    • the voluminous past discussions on the topic
    • considerations of the decisions already made and the need to continue to support those, a.k.a. "legacy considerations"
    • the associated drawbacks of the proposed approach along with issues raised and re-raised in spite of all of that

That's also to say: I have also seen these things done right in other threads, which do a good job of summarizing past issues and discussion, try to introduce something novel or address previously raised problems, and are pragmatic about the pros and cons. I can't say I'm seeing that here.

+1 to both


I should clarify, I'm of the opinion that without

the only thing which is possible is

1 Like

At this point I'll quote josh:

In particular see this comment that gives the teams thinking (as of January 2019) and notes outstanding issues. The comment following it lays out some additional concerns.