glob-parent <5.1.2
Severity: moderate
Regular expression denial of service - https://npmjs.com/advisories/1751
fix available via `npm audit fix`
node_modules/watchpack-chokidar2/node_modules/glob-parent
chokidar 1.0.0-rc1 - 2.1.8
Depends on vulnerable versions of glob-parent
node_modules/watchpack-chokidar2/node_modules/chokidar
watchpack-chokidar2 *
Depends on vulnerable versions of chokidar
node_modules/watchpack-chokidar2
watchpack 1.7.2 - 1.7.5
Depends on vulnerable versions of watchpack-chokidar2
node_modules/watchpack
I just install cookie-parser to cmd.
As mentioned above, there were 4 moderates.
My glob-parent -v is currently 7.19.1
It doesn't work 'npm audit' and 'npm audit fix'
How should I do?
In your package.json, add this target under scripts:
"preinstall": "npx npm-force-resolutions"
Then add this below the scripts:
"resolutions": {
"glob-parent": "^6.0.1"
}
One thing, I don't know if any dependent packages that use an older version will break because of 6.0.1.
I'm the person who wrote the fix for glob-parent that landed in glob-parent#5.1.2. There are (at least) three ways to address this.
First possibility: Update from watchpack version 1 to watchpack version 2. watchpack version 2 does not depend on a vulnerable version of glob-parent. Unfortunately, there is no CHANGELOG file in the watchpack repository, so you'll have to find the relevant breaking changes some other way. Maybe if you have excellent test coverage, you can rely on that. Or if your project is relatively new, then simply building it with watchpack version 2 to begin with will be the way to go.
The second possibility is that if watchpack is a development dependency only and not something used by the user-facing part of your app, then you probably don't need to worry about this at all and can ignore the message. I don't recommend this, but I also have to admit that npm audit warnings can be a little bit boy-crying-wolf sometimes.
The third option is to patch your vulnerable glob-parent with the fix. However, you have to know what your doing (particularly how npm works) to not shoot yourself in the foot and end up undoing the fix without realizing it. So this is also not something I recommend.
If you can update watchpack to 2.x, that is the way to go.
Use the following overrides and It will resolve the Issue
"overrides": {
"chokidar": "3.5.3",
"glob-parent": "6.0.2"
}
Add the above in your package.json and do npm update
Related
I have ran npm audit in my project and I've got the following results.
nth-check <2.0.1
Severity: high
Inefficient Regular Expression Complexity in nth-check - https://github.com/advisories/GHSA-rp65-9cf3-cjxr
fix available via `npm audit fix --force`
Will install #svgr/webpack#6.5.1, which is a breaking change
node_modules/svgo/node_modules/nth-check
css-select <=3.1.0
Depends on vulnerable versions of nth-check
node_modules/svgo/node_modules/css-select
svgo 1.0.0 - 1.3.2
Depends on vulnerable versions of css-select
node_modules/svgo
#svgr/plugin-svgo <=5.5.0
Depends on vulnerable versions of svgo
node_modules/#svgr/plugin-svgo
#svgr/webpack 4.0.0 - 5.5.0
Depends on vulnerable versions of #svgr/plugin-svgo
node_modules/#svgr/webpack
5 high severity vulnerabilities
I'm concerned about the Will install #svgr/webpack#6.5.1, which is a breaking change, I mean, not sure if it will actually break anything in my project. How can I handle this?
In your package.json you can overwrite the resolution of your specific packages.
"overrides": {
"YOUR_PACKAGE_HERE": "YOUR_VERISON_HERE"
},
Bear in mind, this can break the main package you are trying to install as it might depend on new functionality added in the package your are overwriting.
In my project, I have some outdated dependencies that have been flagged by Checkmarx.
However, the dependencies flagged are in react-scripts version 4.0.3. For example, there are packages flagged within react-scripts, i.e ejs, immer, url-parse, debug and some more.
What would be the best way to upgrade these packages, individually or update to the latest react-scripts version, would that solve it?
I'm Ravid, a security researcher in Checkmarx.
Please allow me to address your question.
The best way to work around this issue is to update the "root" (react-scripts in this case) to the latest version.
Once you will update this package to its latest version (5.0.1), the transitive dependencies (AKA the children) will get updated accordingly.
For example, react-scripts uses react-dev-utils which uses immer, once updating react-scripts to the latest, you will notice it uses the latest version of immer.
Please note that a project might use a few different versions of the same package.
For example, react-scripts (latest) uses debug in versions 4.3.4 (latest) as well as 2.69 and 3.27.
It is important to remember then even after updating the "root" package there might still be outdated "children" packages, since some packages are still using vulnerable/outdated package versions.
An example of that would be:
As you can see, react-scripts (latest) uses webpack-dev-server (latest) which uses portfinder (latest) which uses debug 3.2.7 (NOT latest)
The "problem" relies on portfinder, which does not uses the latest version of debug.
Regarding breaking code after updating the dependencies, Checkmarx have an engine that will alert the method, line, and file that was broken At the moment, this feature is internal only but should be production-ready soon enough
I've just started to use Dependabot and encountered an issue with one of its alerts. I was looking for an answer how to handle such vulnerabilities, but didn't fine any proper resource. What I can see that it is a dependency of my deps, so it affects package-lock file.
Here is what Dependabot provided:
Dependabot cannot update glob-parent to a non-vulnerable version
The latest possible version that can be installed is 3.1.0 because of the following conflicting dependencies:
eslint#8.8.0 requires glob-parent#^6.0.1
postcss-mixins#6.2.3 requires glob-parent#^3.1.0 via a transitive dependency on fast-glob#2.2.7
The earliest fixed version is 5.1.2.
I don't have glob-parent in my package.json file - it is just the dependency of my other dependencies. What is the attitude to handle such alerts? Should I dismiss it? As far as I know manually changing package-lock is not the way to go.
I am warned about vulnerabilities in the packages listed in the package-lock.json file of my Node.Js project.
I can follow the advice here and reinstall all the packages with npm install <package-name>, however, I also use other npm projects that use the older versions of those packages, which will not get reinstalled with a simple npm install.
Does it mean I have to go to package-lock.json and manually change all the dependencies to the latest version?
What if they break?
Isn't there a proper way of doing the updates that ensures you won't break the other packages dependent on the old versions?
If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency#latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!
I am working on an application that uses bower.js; it's the first time I use bower, so please correct me if you see anything evidently wrong in my problem description.
------------------------------------------------
Coming from a Ruby background, I expect a package manager to have a .lock file, tracked under git, that tells me exactly which are the versions currently in use. This doesn't seem to happen with bower (am I right?).
A couple of days ago I deleted and re-cloned my repository, and ran bower install, thinking that such command would just install the required versions of the js components.
Then, today I did a one-line fix in a javascript file, compiled application.js using grunt watch, and realised that application.js was automatically filled up with tons of new code from bower component updates I wasn't aware of.
I found out that our bower components were under .gitignore, and that bower install, that I had run a few days ago, had actually updated two components without me noticing it.
When I realised what was happening, I immediately looked into our deployment procedure, which I paste here:
bundle install --path ${SNAP_CACHE_DIR}/.bundle
npm install -g bower grunt-cli
bower cache clean && bower install && bower list
bundle exec cap [our application name] deploy
Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?
Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?
Yes, this may happen and can cause problems. Although the impact will be limited as long as your dependency versions are specified as e.g. "~1.2.3", which will lock the major/minor version and only allow patch level updates.
In contrast to bower, the package manager normally used in node.js environments - npm - has a feature/command called npm shrinkwrap, which creates an npm-shrinkwrap.json file which locks down your dependency versions so that it is safe to run npm install afterwards.
This is probably what you would want.
However, bower as it stands does not have this feature yet - there is a discussion about it going on on Github e.g. here.
I think there currently are the following options to solve this problem in your situation:
Un-ignore and commit your bower_components (very ugly because of the huge amount of noise this produces in git).
Specify your dependency versions down to the patch level, e.g. "1.2.3" instead of "~1.2.3".
Culprit: If your dependencies have sub-dependencies, they might still be specified on the minor-version level, which means that even if your direct dependencies have a predictable version, your transitive dependencies may not.
Stop using bower and use npm instead (interface-/usability-wise, they are almost identical imho) and use npm shrinkwrap to lock down your dependencies.
Cheers, Alex