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).
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.
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.
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.
...is 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.
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.
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.
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
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.