fix: resolve JS NPM security audit failures#3127
Conversation
📝 WalkthroughWalkthroughThis pull request updates npm and related dependencies to newer versions (npm 6.12.6 → 8.18.0, minimatch → 10.2.2/5.2.3), adds resolution entries for ajv and minimatch in the root package.json, updates systeminformation in the dashmate package, and refactors virtual file system handling in .pnp.cjs with improved path resolution, error handling, and asynchronous operations. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
263a998 to
eeef992
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
PastaPastaPasta
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.pnp.cjs:
- Around line 7705-7712: The resolution forcing bn.js to 5.2.3 is incompatible
with several dependencies that require bn.js@4.x; revert/remove the global
bn.js@5.2.3 resolution and instead pin bn.js@^4.x for the packages that need it
(at least `@dashevo/dash-util`, asn1.js, create-ecdh, diffie-hellman) by adding
targeted resolutions (or dependency overrides) that install bn.js@4.x for those
dependents, then regenerate the lockfile so the lock/yarn pnp data (the bn.js
entry) reflects bn.js@4.x for those packages and avoids breaking API changes
between 4→5.
- Line 2541: The .pnp.cjs shows the correct resolved versions but you must
ensure the source-of-truth files are in the PR: verify the root package.json
"resolutions" contains entries for "ajv": "8.18.0", "minimatch": "10.2.2", and
"bn.js": "5.2.3", and confirm packages/dashmate/package.json lists
"systeminformation" at the intended range (^5.30.8); do not manually edit
.pnp.cjs (Yarn generates it) — if either package.json is missing or has the
wrong versions, update the corresponding package.json (root resolutions or
packages/dashmate/package.json), commit the change, and push so the PR includes
those authoritative files.
- Around line 15977-15985: The pinned minimatch version must be 10.2.2 to
remediate GHSA-3ppc-4f35-3m26; update any dependency resolution to ensure
minimatch resolves to "npm:10.2.2" (as shown by the minimatch entry) and verify
runtime compatibility: search for direct imports/uses of minimatch (e.g.
require('minimatch') or import minimatch from 'minimatch') and change them to
the new named export form (e.g. use the exported symbol minimatch) or adjust ESM
imports accordingly, ensure Node runtime meets the 10.x requirement (Node 20 ||
>=22), update lockfiles/constraint files so all consumers get 10.2.2, and run
the test suite and any dependent packages to confirm no breaking changes at
runtime.
In `@package.json`:
- Around line 125-126: The root-level pins for "ajv": ">=8.18.0" and
"minimatch": ">=10.2.1" cause unresolvable transitive conflicts with
ESLint/@eslint/eslintrc (which requires ajv@^6.12.4) and other packages that
expect older minimatch; remove these global constraints from package.json and
instead declare the correct versions where needed: keep ajv@^8.x as a direct
dependency in the workspace packages that use v8 (dapi, dashmate, wasm-dpp) and
allow ESLint to use its bundled ajv@6 by not forcing a global resolution;
likewise, remove the global minimatch override and let dependent packages
resolve their compatible minimatch versions or upgrade ESLint/deps to versions
compatible with minimatch v10 if you intend to standardize on v10; after making
these changes, run an install and verify ESLint and the workspace packages
(dapi, dashmate, wasm-dpp) build and lint correctly.
| ["@grpc/grpc-js", "npm:1.14.3"],\ | ||
| ["@pshenmic/zeromq", "npm:6.0.0-beta.22"],\ | ||
| ["ajv", "npm:8.12.0"],\ | ||
| ["ajv", "npm:8.18.0"],\ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the root package.json resolutions and dashmate package.json changes
echo "=== Root package.json resolutions ==="
cat package.json | jq '.resolutions // empty'
echo ""
echo "=== dashmate package.json systeminformation version ==="
fd -g 'package.json' -p 'packages/dashmate' --max-depth 2 --exec jq '.dependencies.systeminformation // empty' {}Repository: dashpay/platform
Length of output: 1393
🏁 Script executed:
#!/bin/bash
# Find and inspect dashmate package.json
echo "=== Finding dashmate package.json ==="
fd -type f -name 'package.json' | grep dashmate
echo ""
echo "=== Full dashmate package.json content ==="
cat "packages/dashmate/package.json" 2>/dev/null | head -100
echo ""
echo "=== Searching for systeminformation in root resolutions ==="
rg "systeminformation" package.json
echo ""
echo "=== Searching for fast-uri in resolutions ==="
rg "fast-uri" package.json
echo ""
echo "=== Searching for require-from-string in resolutions ==="
rg "require-from-string" package.jsonRepository: dashpay/platform
Length of output: 3270
🏁 Script executed:
#!/bin/bash
# Check the specific lines in .pnp.cjs
echo "=== Checking ajv at line 2541 ==="
sed -n '2540,2542p' .pnp.cjs
echo ""
echo "=== Checking minimatch at line 3121 ==="
sed -n '3120,3122p' .pnp.cjs
echo ""
echo "=== Checking bn.js at line 3379 ==="
sed -n '3378,3380p' .pnp.cjs
echo ""
echo "=== Checking systeminformation at line 9595 ==="
sed -n '9594,9596p' .pnp.cjs
echo ""
echo "=== Searching for fast-uri in .pnp.cjs ==="
rg "fast-uri" .pnp.cjs -A 2 -B 2 | head -20
echo ""
echo "=== Searching for require-from-string in .pnp.cjs ==="
rg "require-from-string" .pnp.cjs -A 2 -B 2 | head -20Repository: dashpay/platform
Length of output: 2058
🏁 Script executed:
#!/bin/bash
echo "=== Searching for bn.js in .pnp.cjs ==="
rg "\"bn\.js\"" .pnp.cjs -A 1 -B 1 | head -30Repository: dashpay/platform
Length of output: 891
Three of four security remediations are in the root package.json resolutions; systeminformation comes from dashmate's direct dependencies.
The .pnp.cjs correctly reflects the intended versions:
- Root resolutions contain
ajv(8.18.0),minimatch(10.2.2), andbn.js(5.2.3) systeminformation(5.31.1) resolves viapackages/dashmate/package.json(^5.30.8)fast-uriandrequire-from-stringare correctly present as transitive dependencies of ajv 8.x
Since .pnp.cjs is auto-generated by Yarn, the primary review should focus on the source-of-truth files (package.json resolutions and packages/dashmate/package.json). Please confirm those files are also part of this PR.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.pnp.cjs at line 2541, The .pnp.cjs shows the correct resolved versions but
you must ensure the source-of-truth files are in the PR: verify the root
package.json "resolutions" contains entries for "ajv": "8.18.0", "minimatch":
"10.2.2", and "bn.js": "5.2.3", and confirm packages/dashmate/package.json lists
"systeminformation" at the intended range (^5.30.8); do not manually edit
.pnp.cjs (Yarn generates it) — if either package.json is missing or has the
wrong versions, update the corresponding package.json (root resolutions or
packages/dashmate/package.json), commit the change, and push so the PR includes
those authoritative files.
| ["bn.js", [\ | ||
| ["npm:4.12.0", {\ | ||
| "packageLocation": "./.yarn/cache/bn.js-npm-4.12.0-3ec6c884f6-10f8db196d.zip/node_modules/bn.js/",\ | ||
| ["npm:5.2.3", {\ | ||
| "packageLocation": "./.yarn/cache/bn.js-npm-5.2.3-b71041c01c-dfb3927e0d.zip/node_modules/bn.js/",\ | ||
| "packageDependencies": [\ | ||
| ["bn.js", "npm:4.12.0"]\ | ||
| ["bn.js", "npm:5.2.3"]\ | ||
| ],\ | ||
| "linkType": "HARD"\ | ||
| }]\ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if any package.json in the repo still pins bn.js to 4.x
rg -n '"bn\.js"' --type json -g 'package.json' | grep -v node_modules | grep -v '.yarn'Repository: dashpay/platform
Length of output: 97
🏁 Script executed:
# Also check the .pnp.cjs file itself for any bn.js@4 references
rg -n 'bn\.js.*npm:4\.' .pnp.cjsRepository: dashpay/platform
Length of output: 42
🏁 Script executed:
# Check yarn.lock or other lockfiles for bn.js versions
rg -n 'bn\.js' --type lock -A 2 -B 2 | head -50Repository: dashpay/platform
Length of output: 2297
bn.js unified to 5.2.3 — critical: multiple packages still require bn.js@4.x
The current yarn.lock reveals actual version conflicts:
@dashevo/dash-util@2.0.3requiresbn.js@^4.6.4asn1.js@5.4.1requiresbn.js@^4.0.0(not 5.x as previously claimed)create-ecdh@4.0.4requiresbn.js@^4.1.0diffie-hellman@5.0.3requiresbn.js@^4.1.0
The forced bn.js@5.2.3 resolution will break these packages due to API changes (particularly the Red class between versions 4→5). While browserify-rsa and browserify-sign do support 5.x, the upstream dependencies cannot use it without version updates first.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.pnp.cjs around lines 7705 - 7712, The resolution forcing bn.js to 5.2.3 is
incompatible with several dependencies that require bn.js@4.x; revert/remove the
global bn.js@5.2.3 resolution and instead pin bn.js@^4.x for the packages that
need it (at least `@dashevo/dash-util`, asn1.js, create-ecdh, diffie-hellman) by
adding targeted resolutions (or dependency overrides) that install bn.js@4.x for
those dependents, then regenerate the lockfile so the lock/yarn pnp data (the
bn.js entry) reflects bn.js@4.x for those packages and avoids breaking API
changes between 4→5.
| ["minimatch", [\ | ||
| ["npm:10.1.1", {\ | ||
| "packageLocation": "./.yarn/cache/minimatch-npm-10.1.1-453db4ee1a-110f38921e.zip/node_modules/minimatch/",\ | ||
| "packageDependencies": [\ | ||
| ["@isaacs/brace-expansion", "npm:5.0.0"],\ | ||
| ["minimatch", "npm:10.1.1"]\ | ||
| ],\ | ||
| "linkType": "HARD"\ | ||
| }],\ | ||
| ["npm:3.1.2", {\ | ||
| "packageLocation": "./.yarn/cache/minimatch-npm-3.1.2-9405269906-e0b25b04cd.zip/node_modules/minimatch/",\ | ||
| "packageDependencies": [\ | ||
| ["brace-expansion", "npm:2.0.2"],\ | ||
| ["minimatch", "npm:3.1.2"]\ | ||
| ],\ | ||
| "linkType": "HARD"\ | ||
| }],\ | ||
| ["npm:5.1.6", {\ | ||
| "packageLocation": "./.yarn/cache/minimatch-npm-5.1.6-1e71429f4c-126b36485b.zip/node_modules/minimatch/",\ | ||
| "packageDependencies": [\ | ||
| ["brace-expansion", "npm:2.0.2"],\ | ||
| ["minimatch", "npm:5.1.6"]\ | ||
| ],\ | ||
| "linkType": "HARD"\ | ||
| }],\ | ||
| ["npm:7.4.6", {\ | ||
| "packageLocation": "./.yarn/cache/minimatch-npm-7.4.6-f3feee458c-0046ba1161.zip/node_modules/minimatch/",\ | ||
| "packageDependencies": [\ | ||
| ["brace-expansion", "npm:2.0.2"],\ | ||
| ["minimatch", "npm:7.4.6"]\ | ||
| ],\ | ||
| "linkType": "HARD"\ | ||
| }],\ | ||
| ["npm:9.0.5", {\ | ||
| "packageLocation": "./.yarn/cache/minimatch-npm-9.0.5-9aa93d97fa-dd6a8927b0.zip/node_modules/minimatch/",\ | ||
| ["npm:10.2.2", {\ | ||
| "packageLocation": "./.yarn/cache/minimatch-npm-10.2.2-834cf8d1d1-e135be7b50.zip/node_modules/minimatch/",\ | ||
| "packageDependencies": [\ | ||
| ["brace-expansion", "npm:2.0.2"],\ | ||
| ["minimatch", "npm:9.0.5"]\ | ||
| ["minimatch", "npm:10.2.2"]\ | ||
| ],\ | ||
| "linkType": "HARD"\ | ||
| }]\ |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
minimatch GHSA-3ppc-4f35-3m26 security advisory patched versions
💡 Result:
For minimatch security advisory GHSA-3ppc-4f35-3m26 (CVE-2026-26996):
- Affected versions:
minimatch< 10.2.1 - Patched (fixed) version: 10.2.1 (upgrade to 10.2.1 or later) [1][2]
Sources: [1] [2]
🌐 Web query:
minimatch npm versions 3.x 5.x 10.x breaking changes
💡 Result:
minimatch 3.x → 5.x (major breaking changes)
- Node.js support tightened:
3.0.0declaresengines: { node: "*" }, while5.0.0requires Node>=10. [1][2] - Dependency major bump:
brace-expansiongoes from^1.0.0(3.0.0) to^2.0.1(5.0.0). [1][2]
minimatch 5.x → 10.x (major breaking changes)
- Node.js support tightened again:
10.0.0requires Node20 || >=22. [3] - Package/API shape change for CommonJS consumers:
- In 5.x,
require('minimatch')returns the function (module.exports = minimatch). [4] - In 10.x, CommonJS entrypoint exports an object of named exports (eg
exports.minimatch = minimatch,exports.Minimatch = ..., etc.). So you typically needconst { minimatch } = require('minimatch')instead of calling the require result as a function. [5]
- In 5.x,
- ESM-first packaging:
10.0.0is published with"type": "module"plus anexportsmap providing both ESM (import) and CJS (require) entrypoints. [3] - Windows glob semantics are explicitly stricter (often surfaces as breaking behavior if you relied on backslashes in patterns): patterns must use forward slashes; backslashes in patterns are treated as escapes unless you opt into
windowsPathsNoEscape. [6]
Notable 10.x “surprise breaking” reported in the ecosystem
- 10.0.2 patch release incident: a reported breaking change where a dependency bump led to
ERR_REQUIRE_ESMfor some consumers in the chain. [7]
Sources: [1] https://raw.githubusercontent.com/isaacs/minimatch/v3.0.0/package.json, [2] https://raw.githubusercontent.com/isaacs/minimatch/v5.0.0/package.json, [3] https://raw.githubusercontent.com/isaacs/minimatch/v10.0.0/package.json, [4] https://raw.githubusercontent.com/isaacs/minimatch/v5.0.0/minimatch.js, [5] https://app.unpkg.com/minimatch@10.1.2/files/dist/commonjs/index.js, [6] https://raw.githubusercontent.com/isaacs/minimatch/v10.0.0/README.md, [7] isaacs/minimatch#257
The minimatch version to 10.2.2 is necessary to fix GHSA-3ppc-4f35-3m26, not an optional choice.
The CVE advisory shows that minimatch versions < 10.2.1 are vulnerable, with no patch available in the 3.x or 5.x branches. The suggested alternatives (">=3.1.3" or ">=5.1.2") cannot fix GHSA-3ppc-4f35-3m26 and are therefore not viable remediation options. The upgrade to 10.2.2 is the only way to resolve this security issue.
That said, minimatch 10.x does introduce breaking changes—most notably, the CommonJS entry point changed from exporting a function directly (const minimatch = require('minimatch')) to named exports (const { minimatch } = require('minimatch')), plus stricter Node.js version requirements (20 || >=22). Verify that your codebase and dependencies actually work with this breaking change. If direct imports of minimatch exist anywhere in the monorepo or closely-coupled dependencies, they may fail at runtime.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.pnp.cjs around lines 15977 - 15985, The pinned minimatch version must be
10.2.2 to remediate GHSA-3ppc-4f35-3m26; update any dependency resolution to
ensure minimatch resolves to "npm:10.2.2" (as shown by the minimatch entry) and
verify runtime compatibility: search for direct imports/uses of minimatch (e.g.
require('minimatch') or import minimatch from 'minimatch') and change them to
the new named export form (e.g. use the exported symbol minimatch) or adjust ESM
imports accordingly, ensure Node runtime meets the 10.x requirement (Node 20 ||
>=22), update lockfiles/constraint files so all consumers get 10.2.2, and run
the test suite and any dependent packages to confirm no breaking changes at
runtime.
| "ajv": ">=8.18.0", | ||
| "minimatch": ">=10.2.1" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's understand the repository structure
find . -name "package.json" -type f | head -20Repository: dashpay/platform
Length of output: 825
🏁 Script executed:
# Find all workspace packages and their minimatch/ajv dependencies
echo "=== Workspace structure ==="
ls -la packages/Repository: dashpay/platform
Length of output: 3617
🏁 Script executed:
echo "=== Searching for minimatch dependencies in workspace packages ==="
rg -n '"minimatch"' packages/*/package.json
echo ""
echo "=== Searching for ajv dependencies in workspace packages ==="
rg -n '"ajv"' packages/*/package.jsonRepository: dashpay/platform
Length of output: 349
🏁 Script executed:
# Also check the root package.json for context
echo "=== Root package.json lines around 125-126 ==="
sed -n '120,135p' package.jsonRepository: dashpay/platform
Length of output: 366
🏁 Script executed:
echo "=== Searching for eslint, mocha, glob, rimraf in all package.json files ==="
rg -n '"(eslint|mocha|glob|rimraf)"' packages/*/package.json package.jsonRepository: dashpay/platform
Length of output: 3209
🏁 Script executed:
# Check yarn.lock for actual resolutions of ajv and minimatch
echo "=== Checking yarn.lock for ajv resolutions ==="
grep -A3 '"ajv"@' yarn.lock | head -50
echo ""
echo "=== Checking yarn.lock for minimatch resolutions ==="
grep -A3 '"minimatch"@' yarn.lock | head -50Repository: dashpay/platform
Length of output: 160
🏁 Script executed:
# Check if yarn.lock exists
ls -lah yarn.lock 2>/dev/null || echo "yarn.lock not found in root"
# Try searching with different pattern
if [ -f yarn.lock ]; then
echo "=== All ajv entries in yarn.lock ==="
grep "^ajv@" yarn.lock | head -10
echo ""
echo "=== All minimatch entries in yarn.lock ==="
grep "^minimatch@" yarn.lock | head -10
fiRepository: dashpay/platform
Length of output: 199
🏁 Script executed:
# Let's also check what versions of ESLint and Mocha expect
# by looking at their package definitions to understand minimatch dependency chain
echo "=== Looking for minimatch in node_modules or checking popular package versions ==="
# Search for references to minimatch in package.json files
rg 'minimatch' packages/*/package.json package.json
# Check if there's a pnpm or npm lockfile
ls -lah package-lock.json pnpm-lock.yaml 2>/dev/null || echo "No npm/pnpm lockfile found"Repository: dashpay/platform
Length of output: 210
🏁 Script executed:
# Try different patterns for yarn.lock entries
echo "=== Searching yarn.lock for ajv entries ==="
grep 'ajv' yarn.lock | head -20
echo ""
echo "=== Searching yarn.lock for minimatch entries ==="
grep 'minimatch' yarn.lock | head -20Repository: dashpay/platform
Length of output: 1234
🏁 Script executed:
# Also check the structure of yarn.lock to understand the format
echo "=== First 100 lines of yarn.lock to understand format ==="
head -100 yarn.lockRepository: dashpay/platform
Length of output: 3721
🏁 Script executed:
# Find which packages require ajv@^6.12.4 in yarn.lock
echo "=== Finding packages that require ajv@^6.12.4 ==="
grep -B5 'ajv: "npm:\^6.12.4"' yarn.lock | head -30
echo ""
echo "=== Finding packages that require minimatch@^3 or @^5 ==="
grep -B3 'minimatch: "npm:\^3.1.2"' yarn.lock | head -20
echo ""
grep -B3 'minimatch: "npm:\^5.0' yarn.lock | head -20Repository: dashpay/platform
Length of output: 1210
🏁 Script executed:
# Check if there's a test command and if we can see test results
echo "=== Checking package.json for test/lint scripts ==="
grep -A2 '"test"\|"lint"' package.json | head -20Repository: dashpay/platform
Length of output: 554
🏁 Script executed:
# Check if any workspace package uses ajv@6 APIs that changed in v8
echo "=== Searching for ajv usage in workspace packages (looking for v6 APIs) ==="
rg -l 'ajv' packages/*/src packages/*/lib --type=js --type=ts 2>/dev/null | head -10
# Check specifically in the packages that declare ajv@8.6.0
echo ""
echo "=== Checking wasm-dpp for ajv usage ==="
find packages/wasm-dpp -name "*.ts" -o -name "*.js" | xargs grep -l 'ajv' 2>/dev/null | head -5Repository: dashpay/platform
Length of output: 320
🏁 Script executed:
# Verify the root config context - is this a monorepo management issue?
echo "=== Checking root package.json structure ==="
cat package.json | grep -A5 -B5 '"workspaces"'Repository: dashpay/platform
Length of output: 383
🏁 Script executed:
# Check the ajv usage in dapi validator
echo "=== packages/dapi/lib/utils/Validator.js ==="
head -50 packages/dapi/lib/utils/Validator.js
echo ""
echo "=== packages/dashmate/src/config/Config.js ajv usage ==="
grep -n -A5 -B5 'ajv' packages/dashmate/src/config/Config.js | head -40Repository: dashpay/platform
Length of output: 2035
🏁 Script executed:
# Verify the actual resolution override in root package.json context
echo "=== Full resolutions section of root package.json ==="
sed -n '/^ "resolutions":/,/^ },$/p' package.jsonRepository: dashpay/platform
Length of output: 1458
ESLint will receive an incompatible version of ajv due to unresolvable transitive dependency conflict.
The root resolution "ajv": ">=8.18.0" forces v8.18.0 globally, but ESLint 9.18.0 depends on @eslint/eslintrc@^3.3.1, which requires ajv@^6.12.4. Since v6 and v8 are incompatible major versions with differing APIs, Yarn Berry's global resolution will break ESLint's internal dependency requirements.
Similarly, "minimatch": ">=10.2.1" forces v10 globally, but ESLint's transitive dependencies (@eslint/object-schema, resolve) require minimatch@^3.1.2 and @^5.0.0 respectively. These version conflicts will cause silent redirection of all minimatch requests to v10.
Workspace packages (dapi, dashmate, wasm-dpp) declare direct dependencies on ajv@^8.6.0 and use v8-specific APIs (.compile(), ajv/dist/2020), confirming they expect v8. However, the transitive ajv@^6.12.4 requirement from ESLint cannot be satisfied by v8.18.0, causing incompatibility at runtime.
Confirm that ESLint and other dev tools function correctly with these resolutions, as the version conflicts indicated above will prevent satisfying their true dependency constraints.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` around lines 125 - 126, The root-level pins for "ajv":
">=8.18.0" and "minimatch": ">=10.2.1" cause unresolvable transitive conflicts
with ESLint/@eslint/eslintrc (which requires ajv@^6.12.4) and other packages
that expect older minimatch; remove these global constraints from package.json
and instead declare the correct versions where needed: keep ajv@^8.x as a direct
dependency in the workspace packages that use v8 (dapi, dashmate, wasm-dpp) and
allow ESLint to use its bundled ajv@6 by not forcing a global resolution;
likewise, remove the global minimatch override and let dependent packages
resolve their compatible minimatch versions or upgrade ESLint/deps to versions
compatible with minimatch v10 if you intend to standardize on v10; after making
these changes, run an install and verify ESLint and the workspace packages
(dapi, dashmate, wasm-dpp) build and lint correctly.
|
Closing in favor of #3139 which fixes the npm audit failures correctly. This PR's approach of force-upgrading transitive dependencies (ajv v6→v8, minimatch v3→v10, bn.js v4→v5) breaks ESLint and other tools that depend on the v6/v3/v4 APIs. PR #3139 uses the correct approach: bumping the direct dependency (systeminformation) and adding audit exclusions for transitive deps that can't be safely upgraded without updating their parent packages. |
1 participant
Issue
CI workflow "JS NPM security audit" failing on v3.1-dev with 4 vulnerabilities (2 HIGH, 1 MODERATE).
CI Run: https://github.com/dashpay/platform/actions/runs/22184195096
Changes
1. Bump systeminformation (HIGH)
systeminformationfrom^5.27.14to^5.30.8inpackages/dashmate/package.json2. Resolve ajv and minimatch (MODERATE + HIGH)
$dataoption. Versions 6.12.6 and 8.12.0 vulnerable, needs >=8.18.0resolutionsin rootpackage.jsonto force secure versions across the monorepo:"ajv": ">=8.18.0""minimatch": ">=10.2.1"Verification
Summary by CodeRabbit