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.

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.

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.

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

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

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

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.

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.

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.

this is yet another reason why i really wished rust had went for namespaced packaging on crates.io. i like so many of the decisions the rust team made, but not this one.

This is incorrect. Package repositories with namespacing are just as vulnerable to these attacks.

Say that a popular package lives at `jack/foo`. An attacker needs only register `jakc` and create a package `foo`, and now anyone typing `blah install jakc/foo` is owned. There's a reason why "namespacing" isn't listed under the "Defenses against typo squatting" section.

Just read my other reply.

Ruby and JS package managers are un-namespaced as well.

Julia too, though there is a central list. I haven't done any tests for this kind of thing.

couldn't you register a typo namespace?

Yes, but then you'd need to also register a ton of packages under that namespace.

That's something that can be flagged for manual review before it gets too far.

maybe I don't understand the namespaces...

but if you are targeting a package `someuser/popularpackage` can you not just register your own malicious `popularpackage` under a typo namespace like `smoeuser`?

Yes, but my thought was it gives a bit more "data" to work with on the package manager's side.

They can see someone registering popular package names under something with a similar namespace and can flag them for manual review (which can be done for namespace-less packages, but there will be much more noise), they can apply things like "This is the first time you are installing a package from 'smoeuser' would you like to continue?", or even require adding a specific namespace "out of band" depending on how paranoid it wants to be.

  > "This is the first time you are installing a package 
  > from 'smoeuser' would you like to continue?"

You don't need package namespacing for this. All package repositories already require a registered account to publish a package.

That's a good point, but honestly I wouldn't be able to tell you the account names of any of the packages i use regularly.

And unless the account name of the package maintainers is brought front-and-center, you aren't necessarily going to know it shouldn't be different until it's too late.

A user doesn't need to be able to recognize the account name, that's the purpose of your aforementioned prompt. Let's consider the possible scenarios for installing "foo/bar":

  I. I've installed anything from the author "foo" before 
     on this machine, implying that I trust "foo".
    A. On a system with namespaced packages, I attempt to 
       install "fpp/bar". I've never installed anything 
       from the author "fpp" before, so I get a prompt.
    B. On a system without namespaced packages, I attempt 
       to install "bsr".
      1. If "bsr" is by an author I trust, then it will be 
         installed. This will be confusing, but is not a 
         security vulnerability. because this author is 
         already running code on my machines.
      2. If "bsr" is by an author I don't trust, then I get 
         a prompt, as in scenario I.A.
  II. I've never installed anything from the author "foo" 
      before on this machine.
    A. On a system with namespaced packages, I attempt to 
       install "fpp/bar". The system prompts me, as in 
       scenario I.A., but because I expect this prompt I 
       don't bother reading it and blindly accept it. The 
       prompt does reiterate the name of the author, but if 
       I didn't catch the typo the first time, there's 
       little chance I'll catch the typo this time. 
       Remember: the value of the prompt is not the 
       reiteration of the name, it's in its unexpected 
       nature, because research has repeatedly shown
       that users, even power users, do not bother 
       reading routine prompts (this is why, e.g., Chrome 
       no longer allows users to bypass the enormously 
       scary warning page that appears when a secure site 
       has a certificate error). My system gets owned.
    B. On a system without namespaced packages, I attempt 
       to install "bsr". The system prompts me, as in 
       scenario I.A., but because I expect this prompt I 
       don't bother reading it and blindly accept it. My 
       system gets owned.

A more complete version of the solution that you're proposing would be to have an actual implementation of a web of trust, but even that doesn't solve all the security problems inherent to package repositories.