Vulnerability of tough-cookie 2.3.2 bundled with package.

[NicolasPelletier]

Good morning,

I am using fsevent version 1.1.2 with NodeJS 6.9.x and a simplified dependency tree looks like this:

┬ fsevents@1.1.2
│ ├─┬ node-pre-gyp@0.6.36
│ │ ├─┬ request@2.81.0
│ │ │ ├─┬ tough-cookie@2.3.2

The problem comes from the version of tough-cookie. There is a vulnerability in tough-cookie version 2.3.2: salesforce/tough-cookie#92. This vulnerability was fixed in 2.3.3 by salesforce/tough-cookie#97.

The Whitesource software flags my application because of this vulnerability.

I don't know why node-pre-gyp is bundled with the package, but I'm pretty sure you have a reason for it so I will not ask to get a clean fsevents package, without bundledDependencies. But, would it be possible to re-publish a version of fsevents with a later version of node-pre-gyp bundled with it ? This will result into a later version of request which will result in version 2.3.3 of `tough-cookie'.

Thanks.

[bnoordhuis]

Updating node-pre-gyp (or rather: request) might be problematic because of request/request#2772.

It might be possible to move node-pre-gyp to devDependencies (see #157 (comment)) but I'm somewhat wary to merge that and discover I broke all of npm.

[NicolasPelletier]

Wow ! Was not aware of this thread on request. This is a big conundrum.

A possible solution would to increase fsevent to version 2.0.0 and support only Node 4/6/8+ ( dealer's choice ). But this is a major step and I can understand that with 90k+ downloads a day, there is some hesitation on doing that, just as the owner of request is reticent of doing it.

Well... I guess we are at an impasse on that one. I can understand that wholeheartedly.

Since most of the code we develop in our team are ultimately servers we deploy on CentOS, I guess I can live with the vulnerability. The problem would come when people on MacOS X start using my package in their projects which might be ultimately deployed on MacOS X. I guess these other teams can do their own security analysis then and decide on their strategy.

I will not close this issue because I still think it is a valid one, but will stop pushing it.

[davidrunger]

Doesn't request@2.81.0 depend on "tough-cookie": "~2.3.0" (https://github.com/request/request/blob/v2.81.0/package.json#L49), and so doesn't that already permit tough-cookie@2.3.3?

[NicolasPelletier]

The problem I think is node-pre-gyp that depends on request@^2.81.0: https://github.com/mapbox/node-pre-gyp/blob/v0.6.36/package.json#L27

This means that if fsevent is simply republished, even if the node-pre-gyp version is frozen to 0.6.36, the packaging will get the latest request which is problematic according to the discussion above.

[CapitanRedBeard]

fsevents@1.1.3 also points to node-pre-gyp@0.6.39. It looks like the latest points to node-pre-gyp@^0.9.0 which would solve this problem.

Anyone using watchpack right now will be opened up to this vulnerability:

├─┬ watchpack@1.5.0
│ ├─┬ chokidar@2.0.2
│ │ ├─┬ fsevents@1.1.3
│ │ │ └─┬ node-pre-gyp@0.6.39

@es128 We should cut a 1.1.4 branch so solve this problem.

[es128]

Resolved in v1.2.0