Conversation
- GHSA-w5p7-h5w8-2hfq (high, ReDoS in trim's whitespace pattern, fixed in 0.0.3) reaches the tree via remark@11 → remark-parse@7 → trim@0.0.1. remark-parse@7 is locked into trim@0.0.1 by its declared range - Both @tryghost/url-utils@5.1.2 (ghost/core direct) and 5.2.3 (via @tryghost/kg-default-cards@10.3.1) traverse the same remark chain, so bumping url-utils alone wouldn't reach trim — a transitive override is the right tool - ^0.0.3 keeps the override inside the same pre-1.0 line so the function signature trim() stays identical for all upstream remark callers - Verified: pnpm audit drops 47 → 46 unique GHSAs (59 → 58 findings); trim resolves to 0.0.3; pnpm test passes (6283/6283 ghost/core; one pre-existing comments-ui editor markdown flake reproduces on clean main and is unrelated)
WalkthroughThe change modifies the package.json file by adding a new entry to the 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
package.json (2)
100-100: 💤 Low value
^0.0.3effectively pins to exactly0.0.3, not the full pre-1.0 rangeThe PR description states the range "keeps the override within the pre-1.0 line," but for
0.0.Zpackages, the caret locks the version entirely — no updates are allowed. Specifically, the npm semver spec defines^0.0.3as>=0.0.3 <0.0.4, not>=0.0.3 <1.0.0.In practice this is harmless: trim's latest published version is
1.0.1and there is no0.0.4, so both ranges resolve to the same0.0.3. The security fix is valid. If the intent genuinely is to allow any compatible pre-1.0 patch that might land, consider making it explicit:♻️ Optional — express the pre-1.0 intent more clearly
- "trim@<0.0.3": "^0.0.3", + "trim@<0.0.3": ">=0.0.3 <1.0.0",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@package.json` at line 100, The trim override entry "trim@<0.0.3": "^0.0.3" currently pins to >=0.0.3 <0.0.4 (caret in 0.0.Z locks patch), so if your intent is to allow wider pre-1.0 updates change the version range for the "trim@<0.0.3" entry to an explicit range such as ">=0.0.3 <0.1.0" (to allow any 0.0.x → 0.0.* patches within 0.1.0) or ">=0.0.3 <1.0.0" (if you intended any pre-1.0 release), and update the package.json dependency key accordingly.
100-100: 💤 Low value
^0.0.3pins to exactly0.0.3, not the full pre-1.0 rangeThe PR description says this keeps "the override within the pre-1.0 line," but under npm semver,
^0.0.3expands to>=0.0.3 <0.0.4, locking to the patch slot only. Sincetrimprogressed directly from0.0.3to1.0.0with no intermediate patches, both interpretations resolve to the same version today, so the override works correctly. If intent is to permit any compatible fix in the0.xline, consider:- "trim@<0.0.3": "^0.0.3", + "trim@<0.0.3": ">=0.0.3 <1.0.0",Either way, the vulnerability is fixed.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@package.json` at line 100, The dependency override "trim@<0.0.3": "^0.0.3" in package.json uses ^ with a 0.0.x version which only allows patch upgrades (>=0.0.3 <0.0.4); update the override to allow the full 0.x range by replacing the version spec with a semver range like ">=0.0.3 <1.0.0" (or another explicit 0.x range you intend) so the override covers all compatible 0.x fixes for the trim package.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@package.json`:
- Line 100: The trim override entry "trim@<0.0.3": "^0.0.3" currently pins to
>=0.0.3 <0.0.4 (caret in 0.0.Z locks patch), so if your intent is to allow wider
pre-1.0 updates change the version range for the "trim@<0.0.3" entry to an
explicit range such as ">=0.0.3 <0.1.0" (to allow any 0.0.x → 0.0.* patches
within 0.1.0) or ">=0.0.3 <1.0.0" (if you intended any pre-1.0 release), and
update the package.json dependency key accordingly.
- Line 100: The dependency override "trim@<0.0.3": "^0.0.3" in package.json uses
^ with a 0.0.x version which only allows patch upgrades (>=0.0.3 <0.0.4); update
the override to allow the full 0.x range by replacing the version spec with a
semver range like ">=0.0.3 <1.0.0" (or another explicit 0.x range you intend) so
the override covers all compatible 0.x fixes for the trim package.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e11bf61c-9946-4967-8038-48366730f1b3
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
package.json
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #27676 +/- ##
=======================================
Coverage 73.19% 73.19%
=======================================
Files 1561 1561
Lines 127072 127072
Branches 15397 15396 -1
=======================================
+ Hits 93012 93013 +1
Misses 33101 33101
+ Partials 959 958 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
1 participant
Why
GHSA-w5p7-h5w8-2hfq (high, ReDoS in
trim's whitespace pattern, fixed in0.0.3) reaches the tree viaremark@11 → remark-parse@7 → trim@0.0.1.remark-parse@7is locked intotrim@0.0.1by its declared range, so the only way to clear the advisory short of replacingremarkis a transitive override.It's worth noting that bumping
@tryghost/url-utilsfrom5.1.2to5.2.3doesn't help here — both versions transit the sameremark@11 → remark-parse@7chain to land on the sametrim@0.0.1. The override is the cleanest fix until a future@tryghost/url-utils(or@tryghost/kg-default-cards) release adopts a newerremarkmajor.^0.0.3keeps the override inside the same pre-1.0 line so thetrim()function signature stays identical for the remark callers consuming it; pinning into1.xwould technically be available but introduces a major-version boundary for a transitive dependency that doesn't otherwise need to move.Test plan
pnpm install— lockfile updates cleanly;trimresolves to0.0.3from insideghost/corepnpm audit— total findings 59 → 58, unique GHSAs 47 → 46; the trim advisory is clearedpnpm test— 6283/6283 ghost/core unit tests pass (the one comments-ui editor markdown flake reproduces on clean main and is unrelated)