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.
Proxying via a local dependency is a good practice, but that can be set up independently of npm.
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.
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.
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?