5 ms·

I think someone needs to audit all versions of all packages on npm. The original eslint maintainer's credentials could have been compromised days ago, via an ol

by Jupe 8y ago

I think someone needs to audit all versions of all packages on npm. The original eslint maintainer's credentials could have been compromised days ago, via an older version of another module; then the credential stealing code could have been removed in a more recent update. I've grepped my entire local code base for 'eval' and 'pastebin'; I seem to be fine. But was I fine yesterday? The "^" wildcard is just evil. And the fallout from this could be incredibly complex. What do you think the original hackers will do with the stolen npm credentials? The paranoid side of me says they are inserting different hacks in any module they can. Ugh... npm is insanely broken.

megaman22 8y ago
It's a mess, I wish I didn't have to associate with the whole ecosystem. I much prefer package managers where you specify an explicit version that you depend on, and have to handle updates yourself - people tell me npm does this now, but I haven't yet seen it work the way I expect it ought to. Of course that kind of a scheme is much more manageable when dependencies are fewer, chunkier, and slower moving. NPM-land, where running npm install downloads half of the internet for a little web page project, is too far gone beyond the pale.
benologist 8y ago
I think developers need to be much more deliberate about the packages they use and try to have a very small node_modules where it's possible to provide some oversight.
- iends 8y ago
  The node package ecosystem is not "designed" to work this way. Everybody is encouraged to use many single purpose packages. The production app I work on at work has over 1000 dependencies. Almost all of them are transitive. (We have maybe 20-30 specified dependencies.)
  - benologist 8y ago
    It's possible to use NPM that way too, I don't think it's "designed" to work in any specific way it just installs what you tell it to. It's important to be pragmatic about blindly-installed and unreviewed 3rd-party code that can read our ENV. Those 20 - 30 modules you like could probably each achieve a significant reduction in their dependencies and you probably could too by exploring their alternatives.
    - mercer 8y ago
      At least in my experience it's surprisingly difficult to find alternative packages that don't rely on all sorts of (often gratuitous) other dependencies.
    - iends 8y ago
      The culture of the Node.js ecosystem is to split things into many small packages, so there is no alternative dependencies with a fewer number of dependencies themselves. (This is drastically different than some ecosystems like Go, where dependencies are practically discouraged.) We try to avoid using obscure packages anyway, so even if there was, we'd be choosing between the popular and well tested package to one that was less popular and tested but had less dependencies. This is probably not a tradeoff we'd be willing to make without a lot of trust in the less popular package.
      - benologist 8y ago
        I have never seen NodeJS (or any other) developers advocating to blindly include third-party code in their applications. I think what you are describing is just a side-effect of not considering the ramifications which only works until NPM (or any package manager) starts being exploited.
- kevin_b_er 8y ago
  This is not possible under the npm/js paradigm of massive module dependency trees. You'll get a module and it will have 10 dependencies and each of those 10 dependencies will each have 5 dependencies. Three of those at the 4th level was an infected eslint package. They've learned precious little since left-pad.
  - cphoover 8y ago
    Right! that's what I thought this is left-pad all over again. Although left-pad was really just a disgruntled publisher... this involves a malicious third party. My suggestion in fixing the later would be to enforce 2FA for publishing of packages that have so many dependents. Award a badge to a release when it is published with 2FA. So for LTS releases they can be verified as manually published. This will impact package consumers decision making process, on whether or not to include a dependency into their package.json.
infogulch 8y ago
window[rot13("riny")]("console.log('hello world')");
void_starer 8y ago
> I've grepped my entire local code base for 'eval' and 'pastebin'; I seem to be fine. I don't know if I'm missing something, but couldn't they have easily called it indirectly like this: console.log(global["ev" + "al"]("40 + 2")); I tested it here: http://rextester.com/FEPVG53848 http://rextester.com/FEPVG53848

by Jupe 8y ago

megaman22 8y ago

It's a mess, I wish I didn't have to associate with the whole ecosystem. I much prefer package managers where you specify an explicit version that you depend on, and have to handle updates yourself - people tell me npm does this now, but I haven't yet seen it work the way I expect it ought to. Of course that kind of a scheme is much more manageable when dependencies are fewer, chunkier, and slower moving. NPM-land, where running npm install downloads half of the internet for a little web page project, is too far gone beyond the pale.

benologist 8y ago

I think developers need to be much more deliberate about the packages they use and try to have a very small node_modules where it's possible to provide some oversight.

iends 8y ago
The node package ecosystem is not "designed" to work this way. Everybody is encouraged to use many single purpose packages. The production app I work on at work has over 1000 dependencies. Almost all of them are transitive. (We have maybe 20-30 specified dependencies.)
- benologist 8y ago
  It's possible to use NPM that way too, I don't think it's "designed" to work in any specific way it just installs what you tell it to. It's important to be pragmatic about blindly-installed and unreviewed 3rd-party code that can read our ENV. Those 20 - 30 modules you like could probably each achieve a significant reduction in their dependencies and you probably could too by exploring their alternatives.
  - mercer 8y ago
    At least in my experience it's surprisingly difficult to find alternative packages that don't rely on all sorts of (often gratuitous) other dependencies.
  - iends 8y ago
    The culture of the Node.js ecosystem is to split things into many small packages, so there is no alternative dependencies with a fewer number of dependencies themselves. (This is drastically different than some ecosystems like Go, where dependencies are practically discouraged.) We try to avoid using obscure packages anyway, so even if there was, we'd be choosing between the popular and well tested package to one that was less popular and tested but had less dependencies. This is probably not a tradeoff we'd be willing to make without a lot of trust in the less popular package.
    - benologist 8y ago
      I have never seen NodeJS (or any other) developers advocating to blindly include third-party code in their applications. I think what you are describing is just a side-effect of not considering the ramifications which only works until NPM (or any package manager) starts being exploited.
kevin_b_er 8y ago
This is not possible under the npm/js paradigm of massive module dependency trees. You'll get a module and it will have 10 dependencies and each of those 10 dependencies will each have 5 dependencies. Three of those at the 4th level was an infected eslint package. They've learned precious little since left-pad.
- cphoover 8y ago
  Right! that's what I thought this is left-pad all over again. Although left-pad was really just a disgruntled publisher... this involves a malicious third party. My suggestion in fixing the later would be to enforce 2FA for publishing of packages that have so many dependents. Award a badge to a release when it is published with 2FA. So for LTS releases they can be verified as manually published. This will impact package consumers decision making process, on whether or not to include a dependency into their package.json.

infogulch 8y ago

window[rot13("riny")]("console.log('hello world')");

void_starer 8y ago

> I've grepped my entire local code base for 'eval' and 'pastebin'; I seem to be fine. I don't know if I'm missing something, but couldn't they have easily called it indirectly like this: console.log(global["ev" + "al"]("40 + 2")); I tested it here: http://rextester.com/FEPVG53848 http://rextester.com/FEPVG53848