Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security issue in node-sass #60

Closed
netsensei opened this issue May 25, 2018 · 1 comment
Closed

Security issue in node-sass #60

netsensei opened this issue May 25, 2018 · 1 comment

Comments

@netsensei
Copy link
Contributor

Github currently flags a vulnerability in a dependency in package-lock.json: hapijs/hoek@2.6.13 is vulnerable per the CVE.

Detailed description

hapijs/hoek is a low-level dependency of the node-sass library via request package. We use node-sass in the front-end workflow via (@symfony/webpack-encore).

node-sass 0.4.9 has a dependency tree which loads the vulnerable package. The maintainers of node-sass need to upgrade their dependencies in order to get the patched versions of their dependencies in order to fix this.

The problem is that this is a no go per sass/node-sass#2170 and sass/node-sass#2355. Upgrading the dependencies would break backward-compatibility with older versions of node that are still in use.

This will be fixed once node-sass 5 is released per sass/node-sass#2312.

Context

It's a devDependency which means that node-sass is only used when there's actual front-end development done in a sandbox environment. The compiled CSS is pre-packaged with (future) stable versions of the datahub. As such, users don't need to run npm install and fetch webpack, node-sass, encore,... and all their dependencies in order to run the datahub.

The other work around would be removing package-lock.json. But that would be bad practice. npm 5 generates the file by default, and it's intended to be committed.

Possible implementation

None.

Your environment

  • node v10.1.0
  • npm 5.6.0
  • yarn 1.7.0
@netsensei
Copy link
Contributor Author

This is fixed. Closing this issue.

The other work around would be removing package-lock.json. But that would be bad practice. npm 5 generates the file by default, and it's intended to be committed.

Removed this anyway since yarn 1.13.0 complains about "mixing package managers isn't a good idea". Instead of npm install, users need to run yarn install to get all their dependencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant