Vue-cli: e2e nightwatch vulnerabilities npm audit fix
Version
3.0.4
Node and OS info
osx, node v10.10.0
Steps to reproduce
1) Install any package from NPM,
2) You'll get prompted to run npm audit fix for 6 vulnerabilities
3) Run npm audit fix
4) Problem still there
5) Run npm audit fix - f
6) Still something with vue-cli-plugin-e2e-nightwatch that keeps bugging
What is expected?
To not have any issues
What is actually happening?
Nightwatch keeps on yelling it has some problems
Well, since I don't event use nightwatch I don't really have a problem with it. But I thought it would be nice to let you know :-)
Cheers guys, you do an amazing job!
imlinus
All 3 comments
imlinus
on 28 Sep 2018
Thanks for the report.
Unfortunately we can't do much about this, it's nested depedencies of nightwatch that are affected, and the semver versions of these packages don't allow an update to a secure version.
Fortunately though, since nightwatch isn't generating any user-facing code, and not running any user-provided input, the type of security problem that's reported here - a DOS attack / command injection - isn't really an issue, at least that's how it seems to me.
So we (including you) can reach out to package maintainers and open an issue about this, hoping they adjust the dependency version ranges, but that's already happening with little effect (see here for example)
LinusBorg
on 29 Sep 2018
Thank you for your quick response Linus!
imlinus
on 29 Sep 2018
Related issues
wahidrahim
路
3Comments
brandon93s
路
3Comments
JIANGYUJING1995
路
3Comments
chasegiunta
路
3Comments
Benzenes
路
3Comments
Most helpful comment
Thanks for the report.
Unfortunately we can't do much about this, it's nested depedencies of nightwatch that are affected, and the semver versions of these packages don't allow an update to a secure version.
Fortunately though, since nightwatch isn't generating any user-facing code, and not running any user-provided input, the type of security problem that's reported here - a DOS attack / command injection - isn't really an issue, at least that's how it seems to me.
So we (including you) can reach out to package maintainers and open an issue about this, hoping they adjust the dependency version ranges, but that's already happening with little effect (see here for example)