3 ms·

It's not about language nor dependency tree per se. It's about what is in that dependency tree. When I depend on a library A in say Python I can be reasonably s

It's not about language nor dependency tree per se. It's about what is in that dependency tree. When I depend on a library A in say Python I can be reasonably sure that it won't download and execute random shit from Internet, nor that it will pull tons of other crap to log to console in colorful ANSI boxes. Basically, it's about NPM ecosystem, which is anything but trustworthy to be run as a terminal application. EDIT: Anyway, didn't mean to shit on author's work. (S)he apparently put fair amount of work into it, and the result looks great.

meowface 5y ago
This is illusory safety. The exact same risks are present in PyPI. There've been plenty of notorious malicious PyPI package incidents and there will be plenty more. If there are dependencies, there could be security risks. JavaScript and NPM just have higher market share, so that's where attackers are more likely to focus their efforts. This is akin to all the people who used to say Macs aren't or can't be infected with malware. What you could do is just audit the package list and try to make a reasonable decision. 35 different packages for a small script, some with almost no GitHub stars or downloads? Maybe cause for concern. A few well-known libraries? Probably less concerning. You'd need to audit the entire lock file to really be sure, but this gives you some idea, at least. It's true that JS developers generally seem to tend towards using a larger number of smaller libraries on average, so it's possible the risk is a bit higher both due to that and the market share, and maybe a few other reasons, but it's not like there are any fundamental differences here. Each project will have their own way of handling dependencies, regardless of the language. You have to evaluate individual projects in any language on a case-by-case basis, and not just stereotype based on the language used. If your comment instead was ripping on the actual contents of package.json (or requirements.txt etc.), then you'd quite possibly have a valid point, but balking at the mere existence of the file is pretty ridiculous.
- bassdropvroom 5y ago
  I think a big problem with the node ecosystem is the lack of standard library. When I'm developing on PHP, Python, or go, they have a vast standard library that means the likelihood of me using a third-party package is relatively low for the most mundane stuff. Comparing that to node, and you'll need to use an npm package for just about anything. This automatically gives you a much larger attack surface. If I understand correctly Deno is supposed to address that, but I have yet to play with it, so not sure how it works.
  - meowface 5y ago
    Definitely a valid counter-point. I'm sure for that and several other reasons, the Node package ecosystem is probably indeed the riskiest of the set. But it's still really foolish for the parent just immediately turn their nose in disgust simply at the sight of a package.json file. Or to say "When I depend on a library A in say Python I can be reasonably sure that it won't download and execute random shit from Internet", which is just completely untrue and misguided in a lot of ways. It's absolutely just as easy for anyone to backdoor a Python package as it is to backdoor an NPM package, and it happens all the time. It's possible it could happen a lot more frequently in the future, too. You could argue that statement's true in a sense, but given that same sense it's also true of Node; it's not a good way of thinking about dependency supply chain attacks.
    - inshadows 5y ago
      You totally misunderstood my point. I wasn't talking about backdoors or supply chain attacks. When I say that a dependency downloads and executes random shit from Internet I meant it as a behavior intended to fulfill its function. The problem is that this is generally acceptable in nodejs/NPM ecosystem. In other words, the gap in dependency hygiene between nodejs/NPM and other ecosystems is huge, and users of it seems not to bother.
      - meowface 5y ago
        >When I say that a dependency downloads and executes random shit from Internet I meant it as a behavior intended to fulfill its function. Can you give an example? I'm aware of the banner thing, but I think that was only a few projects, and that's something else entirely.
        inshadows 5y ago
        See the link in my original post. The other things I'm aware of are ridiculous behaviors of npm packages, like create-react-app, which feels the right thing to do is to spawn my $EDITOR when it sees exception in the log (which it hides), except that the whole terminal session freezes because vim and create-react-app fight for the tty. And there are other things where authors pull in insane amount of dependencies to log in their own colorful fancy way. But then again, I'm not that well versed in nodejs to judge by that experience alone. As I said in the middle, I'm not trying to dismiss author's work. I'm sorry for the tone of my previous replies. This comment thread I spawned is also very off-topic.

meowface 5y ago

This is illusory safety. The exact same risks are present in PyPI. There've been plenty of notorious malicious PyPI package incidents and there will be plenty more. If there are dependencies, there could be security risks. JavaScript and NPM just have higher market share, so that's where attackers are more likely to focus their efforts. This is akin to all the people who used to say Macs aren't or can't be infected with malware. What you could do is just audit the package list and try to make a reasonable decision. 35 different packages for a small script, some with almost no GitHub stars or downloads? Maybe cause for concern. A few well-known libraries? Probably less concerning. You'd need to audit the entire lock file to really be sure, but this gives you some idea, at least. It's true that JS developers generally seem to tend towards using a larger number of smaller libraries on average, so it's possible the risk is a bit higher both due to that and the market share, and maybe a few other reasons, but it's not like there are any fundamental differences here. Each project will have their own way of handling dependencies, regardless of the language. You have to evaluate individual projects in any language on a case-by-case basis, and not just stereotype based on the language used. If your comment instead was ripping on the actual contents of package.json (or requirements.txt etc.), then you'd quite possibly have a valid point, but balking at the mere existence of the file is pretty ridiculous.

bassdropvroom 5y ago
I think a big problem with the node ecosystem is the lack of standard library. When I'm developing on PHP, Python, or go, they have a vast standard library that means the likelihood of me using a third-party package is relatively low for the most mundane stuff. Comparing that to node, and you'll need to use an npm package for just about anything. This automatically gives you a much larger attack surface. If I understand correctly Deno is supposed to address that, but I have yet to play with it, so not sure how it works.
- meowface 5y ago
  Definitely a valid counter-point. I'm sure for that and several other reasons, the Node package ecosystem is probably indeed the riskiest of the set. But it's still really foolish for the parent just immediately turn their nose in disgust simply at the sight of a package.json file. Or to say "When I depend on a library A in say Python I can be reasonably sure that it won't download and execute random shit from Internet", which is just completely untrue and misguided in a lot of ways. It's absolutely just as easy for anyone to backdoor a Python package as it is to backdoor an NPM package, and it happens all the time. It's possible it could happen a lot more frequently in the future, too. You could argue that statement's true in a sense, but given that same sense it's also true of Node; it's not a good way of thinking about dependency supply chain attacks.
  - inshadows 5y ago
    You totally misunderstood my point. I wasn't talking about backdoors or supply chain attacks. When I say that a dependency downloads and executes random shit from Internet I meant it as a behavior intended to fulfill its function. The problem is that this is generally acceptable in nodejs/NPM ecosystem. In other words, the gap in dependency hygiene between nodejs/NPM and other ecosystems is huge, and users of it seems not to bother.
    - meowface 5y ago
      >When I say that a dependency downloads and executes random shit from Internet I meant it as a behavior intended to fulfill its function. Can you give an example? I'm aware of the banner thing, but I think that was only a few projects, and that's something else entirely.
      - inshadows 5y ago
        See the link in my original post. The other things I'm aware of are ridiculous behaviors of npm packages, like create-react-app, which feels the right thing to do is to spawn my $EDITOR when it sees exception in the log (which it hides), except that the whole terminal session freezes because vim and create-react-app fight for the tty. And there are other things where authors pull in insane amount of dependencies to log in their own colorful fancy way. But then again, I'm not that well versed in nodejs to judge by that experience alone. As I said in the middle, I'm not trying to dismiss author's work. I'm sorry for the tone of my previous replies. This comment thread I spawned is also very off-topic.