Update npm on all supported release lines to address CVE scored 9.8 in minimist package

[mleneveut]

Is your feature request related to a problem? Please describe.
The package mkdir 0.5.1 contains a dependency to minimist 0.0.8, which has the CVE-2020-7598, scored 9.8

Describe the solution you'd like
Remove the package mkdirp or find a maintained alternative.

Others

node -v
v12.16.1

npm -v
6.13.4

list mkdirp
npm@6.13.4 /usr/lib/node_modules/npm
+-- cacache@12.0.3
| `-- mkdirp@0.5.1  deduped
+-- cmd-shim@3.0.3
| `-- mkdirp@0.5.1  deduped
+-- gentle-fs@2.3.0
| `-- mkdirp@0.5.1  deduped
+-- libcipm@4.0.7
| `-- mkdirp@0.5.1  deduped
+-- mkdirp@0.5.1
+-- move-concurrently@1.0.1
| +-- copy-concurrently@1.0.5
| | `-- mkdirp@0.5.1  deduped
| `-- mkdirp@0.5.1  deduped
+-- node-gyp@5.0.5
| `-- mkdirp@0.5.1  deduped
+-- pacote@9.5.11
| `-- mkdirp@0.5.1  deduped
`-- tar@4.4.13
  `-- mkdirp@0.5.1  deduped

[mleneveut]

seems to have been forked and released in v1.0.3 without the minimalist deps : https://github.com/isaacs/node-mkdirp

[mscdex]

This should be posted to the npm issue tracker instead.

[mleneveut]

I did, thx

[mcollina]

I think we should keep this open because we'll need to issue new releases on all LTS line.

[sam-github]

Can the subject be changed to something more specific, is this the plan?

Update npm on all supported release lines to address CVE

Right now, subjects suggests we'll be updating a package deep inside npm's deps, which I assume/hope is not the intention.

[mcollina]

The intention should be for npm to do releases for all those lines and we'll just backport those to all lts lines

[mcollina]

cc @nodejs/tsc this is important.

[targos]

I think this is not important because mkdirp doesn't use minimist in its API (only in the CLI, which is never used by npm or any of its dependencies).

[mcollina]

It is because most vulnerability scanners are going to detect this automatically.

[targos]

If we want to quickly fix this on our side, we can probably just rm -rf deps/npm/node_modules/minimist

[sam-github]

I think hacking deps/npm sets a bad precedent, but given a 10.x is going out tomorrow, maybe it can update npm to the latest (assuming latest fixes this).

[richardlau]

I think hacking deps/npm sets a bad precedent, but given a 10.x is going out tomorrow, maybe it can update npm to the latest (assuming latest fixes this).

AFAIK there isn't a fixed version of npm yet. v6.14.2 (the latest npm release) still has minimist@0.08: https://github.com/npm/cli/blob/v6.14.2/node_modules/minimist/package.json

Tracking bug: npm/cli#1027

[MylesBorins]

We've floated patches to npm in the past, fwiw. I would be a bit more comfortable with patching the tree to squelch any dependency warnings than shipping with a version of npm that hasn't gone out in any other release lines.

[lirantal]

I asked the npm folks in the openjs slack and Darcy confirmed they will be shipping an npm release today so if this can wait out a bit for that maybe that can work

[richardlau]

There's an OpenSSL update due out today (#32210). That could potentially go out in the same release as the npm update.

[BridgeAR]

I will wait a tiny bit with the next v13 release to get a fix into that release.

[rvagg]

I don't have an active line to any npm folks these days but if they want to co-ordinate on a node-gyp release then I'd like to hear about it. We have a flagged minimist in our dep tree via mkdirp too but we try and keep our dep ranges roughly in line with npm's too. So for them to ship a "safe" npm will require a "safe" node-gyp.
Can someone pass this on to them: nodejs/node-gyp#2074
Or just contact me directly, my email address is all over the place, or IRC.

(Also, this whole minimist issue is beyond bogus, I hate this binary security culture we have that incentivises certain companies to make package maintainers lives hard).

[rvagg]

Actually, we (node-gyp) probably don't need to do anything to synchronize, we ship with "mkdirp": "^0.5.1" and Isaac has released an 0.5.3 to update the dependency. We don't ship a package-lock.json, so new installs should take care of this, npm just needs to update their deps and it should be taken care of.

[mleneveut]

FYI, as Isaac released a 0.5.3 of mkdirp, a simple npm update (actually two) fixes the CVE in a node 12.x :

cd /usr/lib/node_modules/npm/node_modules/rc && npm update
cd /usr/lib/node_modules/npm && npm update

[ljharb]

What actual vulnerability is being addressed here? The CVE itself seems to indicate that the attack vector is "you can craft a malicious command line argument to attack yourself", which doesn't seem like something particularly urgent.

Additionally, it seems like mkdirp can be updated to v0.5.3 trivially, even as a floating patch. Can that be pulled in and shipped in v13 ASAP, especially if that has to start a two-week clock?

[mcollina]

What actual vulnerability is being addressed here? The CVE itself seems to indicate that the attack vector is "you can craft a malicious command line argument to attack yourself", which doesn't seem like something particularly urgent.

My opinion is that there is no vulnerability. I strongly disagree on considering this a vulnerability on minimist in all form or fashion. If somebody can manipulate the commands passed to a CLI, they are definitely outside the Node.js threat model (and therefore the one of every app for Node.js). My opinion is that the security process failed the community in this specific case. However, the topic is not if minimist is vulnerable or not, it is to avoid Node.js including a vulnerable piece of code.

The problem is that every vulnerability scanner is going to pinpoint Node.js as vulnerable because those files are on disk. This is causing disruption to all enterprise deployments: most companies have a very strict rule of no known vulnerabilities. As a result, we have to ship releases asap to all lines, without waiting for the 2 weeks period.

cc @nodejs/releasers

[jasnell]

I agree 100% with @mcollina. This is unfortunately forcing us to make a release when it should not have. Let's just do it and move on.

[ljharb]

Thanks for clarifying, that position makes sense to me.

[BethGriggs]

v12.x (#32313) and v10.x (#31984) have releases due Tuesday 24th March that the necessary patch/update could be pulled into. Is that timeframe sufficient?

It's possible v13.x could be sooner (@BridgeAR nodejs/Release#487 (comment))

Are we still waiting on a new version of npm or do we just need to float a patch?

[mcollina]

v12.x (#32313) and v10.x (#31984) have releases due Tuesday 24th March that the necessary patch/update could be pulled into. Is that timeframe sufficient?

I think that's sufficient.

Are we still waiting on a new version of npm or do we just need to float a patch?

I don't think npm has fixed it yet unfortunately.

[MylesBorins]

npm update has landed

npm/cli@cc3122a

going to make a PR rn

[mleneveut]

Hi, thanks for your quick and efficient work on this.

Could we release a node 12.x with npm 6.14.4 which seems to fix deeper the issue ? npm/cli#1059

[richardlau]

Node.js 10.20.0, 12.16.2 and 13.12.0 were all updated to use npm 6.14.4.