Ask HN: Why is Node.js more susceptible to supply chain attacks than e.g. PHP?
I guess npm package naming anarchy and dependency rot come to mind, and security weaknesses inherent in distributed FOSS development. But inherently there's nothing a bad js script can do to your server that a malicious php script couldn't have done twenty years ago if you used the wrong package. Why has supply poisoning become such a problem with the Nodejs ecosystem in particular?
16 comments
[ 2.7 ms ] story [ 58.4 ms ] threadMost software developers do not sign their git commits. And if they do, they probably aren't doing it properly (store keys on a YubiKey or only use QubesOS with an isolated dev qube and split GPG).
If you do any sort of dev work, you really need to isolate that activity from the other things you do online and generate a signing only GPG subkey and handle it properly and sign all of your git commits. I think this is vital to ensuring code integrity as if you do not do this, you probably won't even realize when someone has tampered with your code.
Hope this helps.
Because PHP packages are vendored by default, so there's an implicit stopgap on the propagation of issues from upstream.
Because PHP isn't dependent on a single vendor with a single global namespace, which avoids several of the issues you mentioned.
You can basically repeat that for other languages whose ecosystems benefit from the wisdom of years accumulated around package management and library design that Node seems to ignore.
edit: and the more I think about it, I suspect a lot of the bad practices in the modern JS ecosystem are due to the paradigm of having the same language running in the browser and on the server. This creates conflicting incentives in the way things are designed and deployed and one necessarily undermines the other.
What do you mean. Could you give some examples?
For instance, as I understand it, the reason Node packages are so small is to make it efficient to run them in browsers. But that also exponentially increases the brittleness and vulnerability of the code. Optimizing for the always-live continuous deployment processes of web development runs counter to what is necessary for stable and secure code on the backend.
I may be wrong, though, it's just something that occurred to me while I was wondering about this exact problem.
Usage of npm packages in browsers is kind of an after thought, as originally people used a separate dependency management for the browser (bower js)
The NPM ecosystem has a huge focus on reusability of libraries, smaller packages is just an emerging phenomenon when reusability is the goal.
Also, small packages are a way to embrace the Unix philosophy, "do one thing and do it well"
But yes, smaller packages create large dependency chains and a greater attack surface...
npm is also a worse designed cli, just executing npm without any arguments and it will start installing regardless of where you are in the filesystem.
If you are going to target something, you pick what you think is going to get the most effect, thus you pick the in-group, not the out-group.
PHP is in-group in one area and that is Wordpress, and of course it also constantly targeted.
https://www.similartech.com/compare/nodejs-vs-php
whereas node.js is clearly dominant for new websites, and we all use hundreds/thousands of new packages every month without even giving it a second thought
One reason I asked this question is that I've never built a commercial Nodejs project from the ground up, just my own side projects which aren't particularly sensitive targets... but I'm trying to choose between Nodejs and PHP for a new client's business app which is somewhat sensitive. I'd be a lot more excited to write it in Nodejs, but looking down the road at having to maintain it securely for years I'm not sure. The Nodejs environment and keeping on top of dependencies feels risky right now in a way that's inclining me to use the old familiar PHP.
It just struck me as I wrote this that there's a lot I do in PHP that's just part of the language or default plugins, where almost every one of those things requires choosing NPM packages in Nodejs. Even simple stuff like talking to a database or managing sessions or setting up sockets. And the NPM packages get deprecated and renamed, sometimes there are two with very similar names by different authors and it's easy to miss a dash or something. Maybe I'm answering my own question here..
The packages/package manager are not the problem, it's more about the bad habits that you start to get when coding with Node/NPM, basically for every function you write, 9 times out of 10 you can just import a package after 1 import and a command, and so you start to have 200 potential liabilities because you became too lazy to code because it's really easy.
But if you stay at least a bit vigilant it's just as safe to use Node.js(or even safer).
I think it's really mostly about bad habits rather than the lack of functionality in the language.
See feross's reply for a better explanation: https://news.ycombinator.com/item?id=30964442
Things like vendoring, upstream version metadata to reduce redundant network requests, SHA verification, are all easy to add after the fact. Support for arbitrary dependencies on the other hand often require a certain amount of support on the compiler level (to detect conflicting exported data structures) which is why many languages cannot easily switch to newer package management architectures.