Comment by danjoc | Hacker News Reader

Comment by danjoc | Hacker News Reader

This really doesn't seem to address the core issues with NPM.

Packages need to be signed with GPG. Full stop. If anyone is running unsigned executable code blindly, they've already failed. You might as well be running .exe files emailed to you by a Nigerian prince.

https://github.com/npm/npm/pull/4016

Oh. Wow. I'm at a loss for words after finding that... I hope NPM are seriously rethinking this position. shasums are definitely not a substitute for validating gpg signatures by any stretch of the imagination.

Anyway, the worries about package removal are misplaced. If production application builds depend on the central NPM repository, they are set up incorrectly. Dependencies should be proxied via a local dependency repository like Sonatype Nexus or Artifactory. It is unprofessional to have builds set up with dependency directly on a repository not under local control.

If you need to convince someone in charge why you need to do this, I recommend this presentation:

https://www.youtube.com/watch?v=pBJafU0p_Nk

It's good, and worth your hour. TL;DW the six reasons are enumerated at 30:59.

GPG isn't the holy grail. See https://caremad.io/2013/07/packaging-signing-not-holy-grail/

Proxying via a local dependency is a good practice, but that can be set up independently of npm.

>GPG isn't the holy grail.

I don't believe anyone ever said it was. It's a far better approach than using shasums for package integrity though.

>Proxying via a local dependency is a good practice, but that can be set up independently of npm.

That's the point. I see a lot of people hand wringing about removed modules in the future. It's not NPMs job/obligation to provide the javascript world with never ending storage, hosting, and bandwidth. Expecting a third party to host dependencies that make in house apps run is a fool's errand. That strategy can, will, and just did fail.

> It's a far better approach than using shasums for package integrity though.

The point of that article is that it isn't. It only adds integrity if you trust the signer. From the article:

> When attempting to verify a signed file you check the signature against a public key. If the signature matches that public key then everything is kosher. The question then becomes which public key, and therein lies the rub. If you do not have a well defined model of trust then all you’ve done is thrown cryptography at a problem in order to give the people involved the ability to say that their system has signature verification.

> It's not NPMs job/obligation to provide the javascript world with never ending storage, hosting, and bandwidth.

That's true, and a good point that we shouldn't expect it to be this way in all circumstances. On the other hand, allowing people to rip out packages without warning makes for a much worse npm experience. Expecting that all JS developers set up a local proxy for all projects, particularly in a non-professional setting, is also unrealistic. npm is indeed improving the situation here (even if they're not solving all possible situations).

Do you think if would help if npm automatically banked packages locally? It's not quite a company-wide proxy, but it could prevent this from failing on your local machine without too much setup.

Even if the answer to "which public key?" is "the same public key that signed the original version of the package we downloaded when we first added the dependency", that does add something.

>The point of that article is that it isn't. It only adds integrity if you trust the signer.

Simply put, that article is wrong. Trust is not a binary. It's greyscale. While no one ever achieved perfect security, pretty good security is better than none at all.

I find it amusing that this article is published using https, that the certificate is from Let's Encrypt, and Let's Encrypt validates CSRs using an unencrypted side channel (DNS). I mean, what a hypocrite, right? There's a potentially easy exploit in his system and I doubt any of his readers will ever contact him in a secure way to verify his key fingerprint. Why doesn't he now eat his own dog food and just give up and go with http instead of going to the trouble of renewing a certificate every 90 days? By the logic in his article, how can I even trust he published any of that stuff?

> Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shasum check npm already has.

The stance was without an agreed upon way of trusting public keys, you don't get any additional protection beyond shasum. Isn't that true?

>The stance was without an agreed upon way of trusting public keys, you don't get any additional protection beyond shasum. Isn't that true?

No, that is not true. It is demonstrably wrong and was demonstrated this week.

https://medium.freecodecamp.com/npm-package-hijacking-from-t...

shasums do nothing to stop package hijacking. An attacker can regenerate a shasum at will. A GPG signature cannot be forged and it will be very clear if a public key is changed.

Unless you have the resources of a nation-state, generating a SHA256+ collision is infeasible.

I believe your parent is saying that an attacker could publish (or convince you they've published) a package+shasum tagged with a later version than the one you have a shasum for, and you'd blindly "upgrade" to the malicious package.

Specifically, Alice publishes widget-1.0.0, Bob records a dependency on widget ^1.0.0, there's one less barrier to Eve convincing Bob to use her malicious widget-1.0.1. (By contrast if Alice signed widget-1.0.0 and included a public key with it, Bob could check Eve's widget-1.0.1's signature against widget-1.0.0's included public-key and see that they don't match.)

The main problem I see with this is what if Alice loses her key?

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.

>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 package-signer@npmjs.org 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.

    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.

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.

Reply on news.ycombinator.com