Typosquatting programming language package managers

Nice talk! Sounds like there's no silver bullet...

I'm curious to hear your opinion about a combination of digital signing with e.g. keybase/blockchain + reputation system, a sandboxed development environment (mitigates the "short con" risk) and a sandboxed production environment, with the minimum set of permissions required to operate (as well as auditing of course).

Call me pessimistic but I don't see developers taking on the extra friction given the status quo. Though a major data breach or two might change things, as I'm sure we'll find out sooner or later.

Wrong.

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.

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.

I thank my stars every time I get a "Package not found" error due to a typo, because I'm reminded that it could have been much worse.