[laughinghan]

    The idea that they are going to invent a better scheme is dangerous.
    They will screw it up, just like everybody else who ever tried that.

By "screw it up", you mean fail to secure it, right? You don't mean they'll screw up the usability to the point of reducing the ease of registering packages, and the number of registered packages, and to the point of hurting the community.

Which is exactly the point that you're missing. "The idea that they are going to invent a better scheme"—by "better scheme" you're thinking more secure, but the only people under the impression that NPM thinks they're going to invent a more secure system are people making the strawman argument you are. The strawman is that NPM's scheme isn't intended to be "better" in the sense of being more secure, it's intended to be better in the sense of improving the community in all the ways that aren't security.

    You can send an encrypted email to that address and get an encrypted response
    back proving that the owner of that address has a copy of the private key.
    [...]
    You can even store a private key on a Yubikey device to limit theft of
     the private key to the theft of a physical token.

That's wonderful and I love reading about it, I'm sure it works great for you, but surely you're aware that the vast majority of the world doesn't use encrypted email or PGP or any of the other decades-old cryptographic technologies. NPM doesn't think they're going to invent a scheme that's more secure than all that. NPM thinks they're going to invent a scheme that's more successful than all that.

[danjoc]

There's no strawman here. Security is a process, not a product. Cut out a few steps to make a "better scheme" and compromise the entire process.

Anyway, good luck with those root exploits. I'm moving now to blacklist npm from our servers and then entire company. We have regulations to comply with. Knowingly allowing gaping security holes like those shipping in npm would be considered negligence and strictly illegal.