3 ms·

>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

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

by danjoc 11y ago

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?