4.0.3 is the latest version of react-scripts permitted by our project.In order to resolve the vulnerability, we need to bring node-forge from 0.10.0 to 1.3.0, but a sequence of conflicting ancestor dependencies prevents us from doing so: While we don’t have a direct dependency on node-forge, if we zoom in on our project’s dependency tree we can see that we do indirectly depend on a vulnerable version: 4.0.3 The advisory impacts versions earlier than 1.3.0, the patched version released the day before the advisory was published. On March 18, 2022, a high-severity security advisory was published for node-forge, a popular npm package that provides tools for writing cryptographic and network-heavy applications.
The version requirement ^4.0.3, then, can be understood as allowing versions greater than or equal to 4.0.3 and less than 5.0.0. A version requirement like ^4.0.3 (a “caret range”) in npm permits updates to versions that don’t change the leftmost nonzero element in the semver version number. In this post we’ll be looking at security updates.Īs an example, let’s say we have a repository with security updates enabled that contains an npm project with a single dependency on all package managers handle version requirements in the same way, so let’s quickly refresh. With security updates, Dependabot tries to make the most conservative update that removes the vulnerability while respecting version requirements. With version updates, the explicit goal is to keep project dependencies updated to the latest available version, and Dependabot can be configured to widen or increase a version requirement so that it accommodates the latest version. Understanding the challengeĭependabot offers two strategies for updating dependencies: scheduled version updates and security updates. Internally, this would show up as a failed background job due to an update-not-possible error-and we would see a lot of these errors.
0 kommentar(er)
