6 ms·

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 bli

by danjoc 11y ago

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

joeyespo 11y ago
GPG isn't the holy grail. See https://caremad.io/2013/07/packaging-signing-not-holy-grail/ 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.
- danjoc 11y ago
  >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.
  - joeyespo 11y ago
    > 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.
    - caf 11y ago
      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.
    - danjoc 11y ago
      >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?
blueplanet 11y ago
> 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?
- danjoc 11y ago
  >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-the-hijackers-perspective-af0c48ab9922 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.
  - illicium 11y ago
    Unless you have the resources of a nation-state, generating a SHA256+ collision is infeasible.
    - laughinghan 11y ago
      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?
  - laughinghan 11y ago
    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.

by danjoc 11y ago

joeyespo 11y ago

GPG isn't the holy grail. See https://caremad.io/2013/07/packaging-signing-not-holy-grail/ 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.

danjoc 11y ago
>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.
- joeyespo 11y ago
  > 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.
  - caf 11y ago
    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.
  - danjoc 11y ago
    >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?

blueplanet 11y ago

> 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?

danjoc 11y ago
>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-the-hijackers-perspective-af0c48ab9922 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.
- illicium 11y ago
  Unless you have the resources of a nation-state, generating a SHA256+ collision is infeasible.
  - laughinghan 11y ago
    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?
- laughinghan 11y ago
  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.