Repository navigation
fix(deps): resolve minimatch audit finding - #2764
Conversation
Package TarballHow to installgh release download pr-2764-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-1.0.1.tgz |
|
Claude Security Review: no high-confidence findings. (run) |
There was a problem hiding this comment.
AgentCore Harness Review
Verdict: Looks good
Verified the change by applying the diff to a clean v1.x checkout and running bun 1.4.4:
bun install --frozen-lockfilepasses, and a plainbun installregenerates a byte-identicalbun.lock— the lockfile is reproducible and not hand-edited.node_modules/@typescript-eslint/typescript-estree/node_modules/minimatchresolves to11.0.4; the hoistedminimatchstays at3.1.5.bun auditreports "No vulnerabilities found (checked 800 packages)".
The approach checks out:
- The finding is GHSA-g3hv-75wg-m249 (vulnerable range
>=7.0.0 <11.0.1), so10.2.6is affected and11.0.1+is the only fixed line.^11.0.1is the minimal correct bound. typescript-estree@8.68.0declaresminimatch: ^10.2.2, so this is a deliberate semver-major override. Its only usage isuseProgramFromProjectService.js→minimatch(filePath, pattern, { dot: true }). minimatch 11's breaking changes (removal ofmakeRe(),Minimatch#regexp,AST,matchOne(),maxExtglobRecursion) don't touch that call, and the CJSminimatch()export still exists in11.0.4. Even the latesttypescript-estree@8.72.1still declares^10.2.2, so there's no upstream bump that would fix this — the override is the only route.- Scoping to
@typescript-eslint/typescript-estreeinstead of a flat"minimatch": "^11.0.1"is the right call: the hoistedminimatch@3.1.5consumers (eslint,eslint-plugin-import,eslint-plugin-react) rely on the pre-v5 API shape and aren't in the vulnerable range. - The new
@isaacs/nonrecursive-glob-match@1.0.3lock entry is just minimatch 11's new dependency; nothing else in the lock changed.
Non-blocking note for follow-up, not a change request for this PR: minimatch enters the tree via a runtime dependencies path (@aws/agent-inspector@0.6.2 → eslint-plugin-testing-library → @typescript-eslint/utils → typescript-estree), and overrides in a published package's package.json are ignored by consumers' installers. Users installing @aws/agentcore will still resolve minimatch@10.2.6 — unreachable at runtime, since the CLI ships a bundle and never imports the eslint plugins. The durable fix is upstream in @aws/agent-inspector (eslint plugins shouldn't be in dependencies); that's out of scope here and doesn't affect unblocking CI.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## v1.x #2764 +/- ##
=======================================
Coverage 96.54% 96.54%
=======================================
Files 706 706
Lines 58543 58543
=======================================
+ Hits 56521 56522 +1
+ Misses 2022 2021 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Description
Address mismatch audit finding that is causing our CI to fail. Fixed by scoping
minimatchoverride to@typescript-eslint/typescript-estreeand updatingbun.lockto resolveminimatch@11.0.4. This clears the audit finding that failss the linux CI verification job.Type of Change
Testing
How have you tested the change?
bun testbun run test:e2e, or explained why they are not applicable(CI does not run them for you)
bun run typecheckbun run lint:checkbun run format:checkbun run auditbun run secrets:checkbun run buildsrc/assets/, I updated affected snapshots withbun test <test-file> --update-snapshotsand committed themby this PR
command.md(the release workflow regenerates it)Checklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.