Please I've tried all and nothing works.
`# npm audit report
liquidjs <10.0.0
Severity: moderate
liquidjs may leak properties of a prototype - https://github.com/advisories/GHSA-45rm-2893-5f49
No fix available
node_modules/liquidjs
#11ty/eleventy <=2.0.0-canary.18
Depends on vulnerable versions of browser-sync
Depends on vulnerable versions of liquidjs
node_modules/#11ty/eleventy
ua-parser-js 0.8.1 - 1.0.32
Severity: high
ReDoS Vulnerability in ua-parser-js version - https://github.com/advisories/GHSA-fhg7-m89q-25r3
No fix available
node_modules/ua-parser-js
browser-sync >=2.27.6
Depends on vulnerable versions of ua-parser-js
node_modules/browser-sync
4 vulnerabilities (1 moderate, 3 high)
Some issues need review, and may require choosing
a different dependency.`
I've tried to update all dependencies but nothing.
Generally speaking, when dealing with SSGs, the vulnerabilities are not the issue because they are revealing themselves only at the build time, and not the runtime. Generated static website doesn't inherit those vulnerabilities.
Related
I am using resolutions to resolve a vulnerability coming from a nested dependency (#dep/xyz). The nested dependency is using axios 0.21.1 whichhas a vulnerability. I am supposed to upgrade to any compatible version above it.
When I added it to resolutions like below I don't see the update in yarn.lock file for the nested dependency. Please advise.
Below is my package.json file
package.json
{
"name" : "xyz",
dependencies: {
"#dep/xyz" : "2.3.4",
"axios": "^0.21.2"
},
"resolutions": {
"**/**/axios": "^0.21.2"
}
}
yarn.lock which gets created after yarn install of above
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1
axios#^0.21.1, axios#^0.21.2:
version "0.21.4"
resolved "https:..."
integrity sha1-123...=
dependencies:
follow-redirects "^1.14.0"
"#dep/xyz#2.3.4":
version "2.3.4"
resolved "https:..."
integrity sha1-123...=
dependencies:
"#x/d1" "0.2.2"
"#y/d2" "0.9.2"
axios "^0.21.1"
You likely need to upgrade yarn. resolutions does not work with dependencies that have / in their name for yarn versions below 2. See https://github.com/yarnpkg/yarn/issues/4874
For starters, you don't need to do any resolution pinning. #dep/xyz#2.3.4 is pulling in axios with semver specification of "^0.21.1". In this context it will accept any version that is both >=0.21.1 and <0.22.0. You need only to use yarn to update the version of axios being resolved. I would advise AGAINST resolution pinning when you don't need to, because that can cause long-term incompatibility. If in the future axios has version >=0.22.0 that you or your dependencies are trying to consume, your resolution setting will force those down to be something within the range >=0.21.2 && <0.22.0.
More directly to your question - I don't see anything that looks wrong. The lockfile is doing exactly what I would expect. Your resolution of "axios#^0.21.2" is being respected, as it's pulling in 0.21.4 which abides by that (even though like I said a resolution is not necessary to achieve that). You haven't done any kind of resolution pinning associated with #dep/xyz (nor should you) so nothing is changed there.
My repo in github show the following alert :
Dependabot cannot update ssri to a non-vulnerable version. The latest possible version that can be installed is 6.0.1 because of the following conflicting dependencies:
terser-webpack-plugin#2.3.8 requires ssri#^7.0.0 via cacache#13.0.1
webpack#4.46.0 requires ssri#^6.0.1 via a transitive dependency on
cacache#12.0.4
The earliest fixed version is 8.0.1.
As far as I known, I should update the root package (which is terser-webpack-plugin) in package.json to a newer version, but how to determine the minimum version that can support the non-vulnerable version of the dependency (in this case ssri 8.0.1) since I don't want to update to a too high version and risk breaking things. I am thinking of manually checking through all the release version of terser-webpack-plugin, but it's very tedious and seem wrong to check like that. Any suggestions ?
To speed up the process and save installing each version and its associated dependency tree, we can use npm-remote-ls (https://stackoverflow.com/a/26005786/2815338)
Firstly get the list of available versions:
> npm view terser-webpack-plugin versions
[
'1.0.0', '1.0.1', '1.0.2', '1.1.0', '1.2.0',
...
Then run npm-remote-ls for each version after your current one and filter on the relevant dependency, e.g.
> npm-remote-ls terser-webpack-plugin#3.0.0 | grep ' ssri#'
??? ?????? ssri#8.0.1
??? ??? ??? ?????? ssri#6.0.2
In this case terser-webpack-plugin#5.0.0 is the first with only fixed versions of ssri (8.0.1), and 5.1.0 appears to not include ssri at all, presumably due to webpack no longer depending on cacache.
N.B. the question marks appear to be due to encoding of characters that npm-remote-ls uses to display a tree structure. You could also use Select-String in PowerShell, but this appears to show different (incorrect) characters instead.
Using semver as the standard, so I have this package version:
0.0.108
so in package.json for a Node.js project, I might have something like:
"foo":"^0.0.108"
my question is - using semver notation, how can I tell NPM not to install anything below 0.0.108? For example, 0.0.107 is unacceptable, but 0.0.109, or 0.0.111 is ok?
If you don't want anything in 0.1.x, then this should work
>=0.0.108 <0.1
If you are okay with any future versions, such as major releases, then you only need
>=0.0.108
Note the semver spec (Section 4) and the npm documentation on semver (Caret Ranges) both suggest there can be breaking changes for every release when the minor version number is still 0, so you may have to deal with those if you decide not to use ^0.0.108.
We've migrated from Nexus 3.01.01 to 3.5.1-02. In the process we had to migrate internally published npms. One of those is the kendo-ui (commercial one) from Telerik/Progress. We have downloaded the licensed copy from Telerik and publishing it to our local nexus for consumption by our developers.
However the publishing fails with an error during payload parsing. I can publish the same tar without an issue to the older (3.01.01) nexus, so the tar/payload it self is OK.
The error seem to be at the point of trying to parse the npm payload. I can also publish a demo/simple npm (both scoped and non-scoped) without an issue. Spend the whole day trying to figure this out with no luck - appreciate any pointers or advice.
2017-09-06 18:49:09,160+0800 WARN [qtp762281666-4116] MIDALLE
org.sonatype.nexus.repository.httpbridge.internal.ViewServlet -
Failure servicing: PUT /repository/npm-hosted/#progress%2fkendo-ui
java.lang.IllegalStateException: Unexpected token VALUE_NULL at
[Source: java.io.InputStreamReader#1ebad5c7; line: 1, column: 896] at
com.sonatype.nexus.repository.npm.internal.NpmPublishParser.parseValue(NpmPublishParser.java:150)
at
com.sonatype.nexus.repository.npm.internal.NpmPublishParser.parseObject(NpmPublishParser.java:174)
at
com.sonatype.nexus.repository.npm.internal.NpmPublishParser.parseValue(NpmPublishParser.java:136)
at
com.sonatype.nexus.repository.npm.internal.NpmPublishParser.parseObject(NpmPublishParser.java:174)
at
com.sonatype.nexus.repository.npm.internal.NpmPublishParser.parseValue(NpmPublishParser.java:136)
at
com.sonatype.nexus.repository.npm.internal.NpmPublishParser.parsePackageRoot(NpmPublishParser.java:123)
at
com.sonatype.nexus.repository.npm.internal.NpmPublishParser.parse(NpmPublishParser.java:98)
at
com.sonatype.nexus.repository.npm.internal.NpmRequestParser.parseNpmPublish(NpmRequestParser.java:81)
at
com.sonatype.nexus.repository.npm.internal.NpmRequestParser.parsePublish(NpmRequestParser.java:60)
at
com.sonatype.nexus.repository.npm.internal.NpmHostedFacetImpl.putPackage(NpmHostedFacetImpl.java:85)
at
com.sonatype.nexus.repository.npm.internal.NpmHandlers$3.handle(NpmHandlers.java:172)
at
org.sonatype.nexus.repository.view.Context.proceed(Context.java:80)
Here's the gist for the full error from the nexus log.
This issue was resolved in scope of https://issues.sonatype.org/browse/NEXUS-14385
Fix Version/s:
3.6.1
There was a problem with parsing null values in package.json
I got this to work however I'm still trying to figure out the impact of the change. Please be cautious if you apply the same 'hack' to get this to work. I had to do this, because there was several other project teams that was getting affected.
In a nutshell I had to strip out few keys from the package.json of the kendo-ui package. My analysis is that these settings makes npm issue a network call that fails in our constraint environment.
The package.json keys that I removed are as follows.
First section
"_resolved": "https://registry.npm.telerik.com/#progress%2fkendo-ui/-/kendo-ui-2017.2.621.tgz",
"_shasum": "09a652ead21700716dd5a50f9e86e9bffcea640e",
"_shrinkwrap": null,
Second section
"dist": {
"shasum": "09a652ead21700716dd5a50f9e86e9bffcea640e",
"tarball": "http://registry.npm.telerik.com/#progress%2fkendo-ui/-/kendo-ui-2017.2.621.tgz"
},
I'd really appreciate if someone who know more about npm and npm definitions can inform the purpose of these settings in the package.json and potential impacts of removing them.
We had been using version 0.11.0 of angular-bootstrap from npmjs. It appears that version is no longer available on npmjs. From the commands below does this mean that someone actually unpublished the older packages?
prompt:~$ npm view angular-bootstrap time
{ modified: '2015-01-12T06:48:54.881Z',
created: '2014-01-29T21:54:32.213Z',
'0.0.1': '2014-01-29T21:54:37.589Z',
'0.0.2': '2014-01-29T22:03:08.814Z',
'0.0.3': '2014-01-29T22:51:49.998Z',
'0.0.4': '2014-02-11T15:14:17.078Z',
'0.11.0': '2014-06-24T07:06:56.435Z',
'0.13.0-SNAPSHOT': '2014-12-02T13:05:43.151Z',
'0.12.0': '2015-01-12T06:46:41.986Z' }
prompt:~$ npm view angular-bootstrap versions
0.12.0
I agree, the package seems to have been unpublished. You can still access it from the github history, as follows:
$ npm install "angular-ui/bootstrap#0.11.0"
(note that you may not need quoting, but some shells will interpret the # as a comment-begin character.) You can also use this syntax in dependencies inside package.json
If you have a project in production that depends on this, you should probably make a fork of the angular-ui/bootstrap repository and point towards that.
(I had some difficulty making this work on Windows, but it looks like you're on a Unixy system, so you should be fine.)
Ticket discussing this and the future is at https://github.com/angular-ui/bootstrap/issues/1636