[tatterdemalion]

This is obviously not true. If `serde` resided at `erickt/serde` (as the counterproposal for Rust would've had it), I could create `erict/serde` or `erick-t/serde` or any other variations of erickt's handle.

The only way this is 'solved' is if some third party authority hands out top level names and refuses to register names that are similar to other names for some definition of similar. The number of levels between top level and package name is irrelevant.

[zardeh]

Well, you could also solve it by saying that the post slash names are unique. ie. There can't exist zardeh/serde if erickt/serde already exists. Then the author-name works as a logical checksum, and you aren't any worse off than you were with a global namespace.

[kibwen]

The purpose of a namespace is to make it possible to disambiguate two otherwise identical identifiers. If you force package names to be unique across all namespaces, then you don't have namespaces at all, you just have a single global namespace where you're forced to prepend an author name to the package name.

[zardeh]

I know, I wasn't suggesting this as a namespacing solution, but instead a typo-prevention one.

[tatterdemalion]

That reduces the likelihood of success (erick-t/srede requires 2 typos) but doesn't eliminate the possibility.

[zardeh]

True, but two simultaneous and specific typos is much, much less likely than a single one.

[kzrdude]

The name is just one part of the problem.

There's another solution (like debian does), auditing what the package itself does, so that you don't allow malicious code into the repository.

[airless_bar]

You are obviously wrong.

While attacking a single package would be possible, covering any interesting amount of "typo"-space would require registering huge amounts of namespaces.

If package manager developers are smart, the allocation of namespaces is also handled externally and associated with some cost (e. g. domain names).

Therefore these kinds of attacks become impractical.

[tatterdemalion]

While a package manager could require something like a domain name to authenticate, its much more common for them to require something with a much lower barrier to entry, like a GitHub account. I don't agree that this design decision means they are 'not smart' (nor do I think having a single namespace is a 'beginner mistake,' but whatever).

Package managers like these approach social networks, which has many advantages but carries the disadvantage of opening users to attacks that resemble social network phishing attacks. We could mitigate this by rolling back to package managers with higher barriers to entry, but I think that is not likely to happen.

You clearly would prefer to use a more adjudicated, managed package manager, with a higher barrier to publish and stronger rules about naming. That's a reasonable thing to want, but it would be better of you if you didn't act like people who want something which conflicts with that goal are stupid.