Version 1.1.4 (the latest version as of this writing) has dependencies with known security vulnerabilities. Thank you in advance for looking into this! :smile:
Yes
Yes
security, vulnerability, hoek
node -v
: v8.11.1npm -v
: 6.0.0yarn --version
(if you use Yarn): N/Anpm ls react-scripts
(if you havenβt ejected): [email protected] /home/rdebeasi/Projects/ganymede
βββ [email protected]
npm install
npm ls hoek
[rdebeasi@rdebeasi ganymede]$ npm ls hoek
[email protected] /home/rdebeasi/Projects/ganymede
βββ¬ [email protected]
βββ¬ [email protected]
βββ¬ [email protected]
βββ¬ [email protected]
βββ¬ [email protected]
βββ¬ [email protected]
βββ¬ [email protected]
βββ¬ [email protected]
β βββ [email protected] deduped
βββ¬ [email protected]
β βββ¬ [email protected]
β βββ [email protected] deduped
βββ [email protected]
βββ¬ [email protected]
βββ [email protected] deduped
See also "Security vulnerability: hoek" in the Jest repo
N/A
This dependency is only used in tests so I don't think it's practically relevant.
Makes sense. Thanks for the quick reply!
For what it's worth, a couple of those vulnerabilities are introduced through webpack-dev-server
. This is still of course an issue that shouldn't affect production environments, but I bet there are at least a few people out there running the dev server in prod. :)
Quick update: it sounds like the vulnerability report on hoek 4.2.1 is a false positive. The issues in the Snyk test do seem to be legitimate, though.
Snyk is reporting macaddress is vulnerable as well. Are you aware of it? https://snyk.io/test/npm/create-react-app
I don't see anything there.
Oops wrong link. Here is the correct one: https://snyk.io/test/npm/react-scripts/1.1.4 - can you see it now?
It would seem macaddress
is the culprit, which is a dependency of cssnano
which is a dependency of css-loader
. Looks like there's a fix for cssnano
already so updating dependencies should work here.
To be fair, this whole thing reeks of code smell. Why cssnano
needed a unique id package when one can be written two dozen characters is beyond me.
Because common functionality should be abstracted. In scale small highly shared utils subtract source size significantly and allow sharing fixes to common problems be shared easily
If you look at the vulnerability description, it says it only matters if the outside code has control over the argument (which it doesnβt). So again, this doesnβt affect us in any way.
As I have explained in https://github.com/facebook/create-react-app/issues/4479#issuecomment-390146097 thereβs no actual vulnerability youβre being affected here.
Not exactly inspirational for a newcomer though. Need a way to either upgrade past it or silence the warning.
Do you think we're happy this is the case? π It's just as annoying to me to keep responding to five different threads about it, as it is to you to see a message like this.
I don't know what to suggest to you. We didn't turn these warnings on. Either you did it, or npm did it by default. (I don't know which one is the case.)
We can't fix it without the downstream dependency updating. When this happens, we'll happily cut a patch. You can help too!
I have same with macaddress
:
βββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β critical β Command Injection β
βββββββββββββββββΌβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Package β macaddress β
βββββββββββββββββΌβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Dependency of β react-scripts β
βββββββββββββββββΌβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Path β react-scripts > css-loader > cssnano > β
β β postcss-filter-plugins > uniqid > macaddress β
βββββββββββββββββΌβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β More info β https://nodesecurity.io/advisories/654 β
βββββββββββββββββ΄βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Package was updated 3 years ago.
We didn't turn these warnings on. Either you did it, or npm did it by default.
That's right, npm added npm audit
and returns vulnerability report on npm install
.
If you look at the vulnerability description, it says it only matters if the outside code has control over the argument (which it doesnβt). So again, this doesnβt affect us in any way.
In many companies npm audit
or nsp check
(before) used in deployment flow to block deployment if vulnerabilities was found. It is not always possible to switch checking off or allow deployment with a failed check.
Weβre happy to take a pull request that updates the dependency or switches it. It might be that youβll need to send it to a few underlying packages.
I donβt personally have the time to work on this right now. Are you willing to help out since it was your company that enabled these checks and is affected by the false positives?
both hoek and macaddress are no longer present in [email protected] and @next
Most helpful comment
This dependency is only used in tests so I don't think it's practically relevant.