cli-shared-utils using a node-ipc version that contains protestware

[donan]

Version

5.0.1

Environment info

System:
    OS: Windows 10 10.0.19042
    CPU: (12) x64 Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz
  Binaries:
    Node: 12.16.3 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.15 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 7.24.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 98.0.4758.102
    Edge: Spartan (44.19041.1266.0), Chromium (99.0.1150.39)
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.2.1
    @vue/babel-helper-vue-transform-on:  1.0.2
    @vue/babel-plugin-jsx:  1.1.1
    @vue/babel-plugin-transform-vue-jsx:  1.2.1
    @vue/babel-preset-app:  5.0.1
    @vue/babel-preset-jsx:  1.2.4
    @vue/babel-sugar-composition-api-inject-h:  1.2.1
    @vue/babel-sugar-composition-api-render-instance:  1.2.4
    @vue/babel-sugar-functional-vue:  1.2.2
    @vue/babel-sugar-inject-h:  1.2.2
    @vue/babel-sugar-v-model:  1.2.3
    @vue/babel-sugar-v-on:  1.2.3
    @vue/cli-overlay:  5.0.1
    @vue/cli-plugin-babel: ~5.0.0 => 5.0.1
    @vue/cli-plugin-eslint: ~5.0.0 => 5.0.1
    @vue/cli-plugin-router: ~5.0.0 => 5.0.1
    @vue/cli-plugin-vuex:  5.0.1
    @vue/cli-service: ~5.0.0 => 5.0.1
    @vue/cli-shared-utils:  5.0.1
    @vue/component-compiler-utils:  3.3.0
    @vue/web-component-wrapper:  1.3.0
    eslint-plugin-vue: ^8.0.3 => 8.5.0
    vue: ^2.6.14 => 2.6.14
    vue-eslint-parser:  8.3.0
    vue-hot-reload-api:  2.3.4
    vue-loader:  17.0.0 (15.9.8)
    vue-router: ^3.5.1 => 3.5.3
    vue-style-loader:  4.1.3
    vue-template-compiler: ^2.6.14 => 2.6.14
    vue-template-es2015-compiler:  1.9.1

Steps to reproduce

Node-ipc added a new dependency called peacenotwar to the latest version and due to that everytime you do a run serve it creates a war protest file on your desktop.
RIAEvangelist/node-ipc@1220522
https://github.com/RIAEvangelist/peacenotwar

What is expected?

Vue cli cli-shared-utils should use an older node-ipc version

What is actually happening?

It's using the latest

[haoqunjiang]

Fixed in 5.0.3 and 4.5.16. Thanks for the report!

[lorand-horvath]

@sodatea Thanks for fixing this so quickly, very much appreciated!

[EJTH]

Why continue using an untrustworthy package from an untrustworthy vendor?
node-ipc should be replaced by alternatives.

[LinusBorg]

Would you prefer:

a) We don't continue using it and break Vue CLI until we have found and implemented a replacement
b) We continue using it - locked to a safe version - until we have found and implemented a replacement

On that note: Could you name a suitable replacement? Are you willing to send a PR? We would be happy to merge it.

[EJTH]

Implementing IPC through sockets is trivial and could be done even without dependencies entirely. I know that node culture is to never write code yourself, not even one liners, so here is an alternate package:
https://github.com/lanmower/hyper-ipc

I'd gladly look into replacing and contributing if trustworthiness is not a priority for paid vue team.

[lorand-horvath]

@EJTH Can we trust hyper-ipc? Judging from the adoption rate, I don't.

I have a question that I still have no clear answer for, so I hope someone more knowledgeable can give a proper response:

Can we be sure that the locked node-ipc version 9.2.1 is and will always be trustworthy in the future? Is it possible for the node-ipc author to modify that particular version with different code and replace the 9.2.1 package on npm? Can we trust that 9.2.1 will always remain unaltered on npm?
I guess there's an obvious response/explanation to this, but I'm still willing to hear it.

[haoqunjiang]

Implementing IPC through sockets is trivial and could be done even without dependencies entirely.

1. It's very likely to break backward compatibilities;
2. And we need to be very careful about the possible regressions and vulnerabilities of the not-widely-used new package.

---

Can we be sure that the locked node-ipc version 9.2.1 is and will always be trustworthy in the future?

No, transitive dependencies may break things too. So I'm gonna ship a version that bundles node-ipc and all its dependencies.

Is it possible for the node-ipc author to modify that particular version with different code and replace the 9.2.1 package on npm?

Not possible.

Can we trust that 9.2.1 will always remain unaltered on npm?

Yes.

[lorand-horvath]

@sodatea Indeed, node-ipc 9.2.1 depends on several other packages from RIAEvangelist (event-pubsub, js-message, js-queue, node-cmd), which are allowed to accept minor & patch updates, so they need to be locked down to safe versions as well:

 "dependencies": {
    "colors": "*",
    "event-pubsub": "4.2.3",
    "js-message": ">=1.0.5",
    "js-queue": ">=2.0.0"
  },
  "devDependencies": {
    "codacy-coverage": "^2.0.0",
    "jasmine": "^2.4.1",
    "istanbul": "^0.4.1",
    "node-cmd": ">=1.2.0"
  }

[haoqunjiang]

devDependencies of a dependency will not be installed during npm install.
The only risky transitive dependency is easy-stack@^1.0.1, which is a transitive dependency of js-queue@2.0.2.

https://unpkg.com/browse/node-ipc@9.2.1/package.json#L12
https://unpkg.com/browse/js-queue@2.0.2/package.json#L33

[lorand-horvath]

@sodatea What about the js-message@1.0.7 dependency? Same author...