[laughinghan]

A GPG signature has major usability problems. From where do you get the public key to verify the GPG signature against?

If it's from NPM, an attacker who could convince you to download the wrong package could convince you to download the wrong public key, too.

If it's from previous versions of the package, what happens if the author loses the public key, or if package ownership needs to be transferred (another name dispute, or the author abandons their package)? Does NPM force people installing the package to decide whether to accept the new key? If NPM merely warns people installing the package, the situation is again barely better than an NPM-provided shasum.

[danjoc]

>From where do you get the public key to verify the GPG signature against?

PGP key servers:

hkps.pool.sks-keyservers.net wwwkeys.pgp.net pgp.mit.edu

There are plenty more. You upload a public key, they relay them around. Read all about it.

http://pgp.mit.edu/faq.html

You can also attach an email address to the public key. 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. Now you just have to trust that [e-mail] or whoever can keep his private key safe. 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.

Not having gpg signed packages is bad enough. Actively discouraging them and denying that pull request is mind-blowing to me personally. 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.

Schneier's Law: Any person can invent a security system so clever that he or she can't imagine a way of breaking it.

[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.