chore(deps): pin pnpm release-age window, floor-pin advisory fixes (LAB-1020) - #89
chore(deps): pin pnpm release-age window, floor-pin advisory fixes (LAB-1020)#8927Bslash6 wants to merge 3 commits into
Conversation
…AB-1020) Renovate becomes the sole dependency-PR bot (Dependabot security-update PRs are disabled at the repo level; the alert feed stays on). pnpm's release-age quarantine is pinned to 1440 min — the pnpm 11 built-in default CI already runs — so the policy no longer moves silently with package-manager bumps. Floor-pins remediate the open high advisories that would red the security job on any PR: postcss (GHSA-r28c-9q8g-f849), brace-expansion 2.x/5.x (GHSA-3jxr-9vmj-r5cp, GHSA-mh99-v99m-4gvg), js-yaml (GHSA-52cp-r559-cp3m), sharp (GHSA-f88m-g3jw-g9cj), protobufjs (GHSA-j3f2-48v5-ccww). New floors are bounded to their current major so a lockfile refresh cannot jump majors. brace-expansion 2.1.3 (same-day security backport) enters via a version-scoped minimumReleaseAgeExclude; GHSA-mh99 is audit-ignored only for advisory-metadata lag — the fix is installed on every resolved line.
This comment has been minimized.
This comment has been minimized.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 37 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughThe PR documents dependency update policies and configures pnpm with a release-age quarantine, an audit advisory exception, and updated transitive dependency version floors. ChangesDependency policy and security floors
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
- ignoreGhsas: document the graph-wide safety invariant (only valid while the brace-expansion floor-pins exist and only 2.x/5.x lines resolve) and add a hard re-evaluation date. - Correct the exclude removal date (window clears 2026-07-29 ~10:17 UTC, so deletable from 2026-07-30). - Full GHSA ids in override comments (grep-ability); point the 5-day Renovate window claim at its owning repo.
This comment has been minimized.
This comment has been minimized.
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In `@CONTRIBUTING.md`:
- Line 86: Update the “Release-age quarantine” section in CONTRIBUTING.md to
state that local pnpm install commands can also fail when no version satisfying
the range has aged beyond minimumReleaseAge. Retain the existing explanation of
frozen-lockfile and tool-generated lockfile behavior, but remove the implication
that the gate only affects lockfiles created by tools that ignore the setting.
In `@pnpm-workspace.yaml`:
- Around line 20-32: Add a CI validation step for the GHSA-mh99-v99m-4gvg ignore
that inspects the lockfile and fails when any brace-expansion major other than
the explicitly supported 2.x and 5.x lines is resolved. Keep the existing
auditConfig.ignoreGhsas entry and overrides unchanged, and ensure the guard
covers all workspace dependency resolutions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: cb0e74b0-1594-451b-9226-c4a9fbdb1aae
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (2)
CONTRIBUTING.mdpnpm-workspace.yaml
…LAB-1020) The graph-wide GHSA-mh99-v99m-4gvg ignore is sound only while every resolved brace-expansion sits on a floor-pinned 2.x/5.x line. That was documented as a SAFETY INVARIANT comment and enforced by nothing, so a transitive pulling a third major would have been silently un-audited by 'pnpm audit'. Add a security- job step that reads the resolved majors out of the lockfile and fails on any line outside 2/5, or on brace-expansion leaving the graph (dead ignore). The guard swallows grep's no-match exit deliberately: under pipefail it would otherwise abort the step with no output, reproducing the silent-failure shape this PR exists to remove. Verified against three lockfiles - real (pass), rogue 1.x injected (fail, names the major), absent (fail, names the dead config). Also correct CONTRIBUTING.md: the quarantine does not only bite tool-written lockfiles. A range whose every candidate is younger than the window has nothing legal to resolve to and errors locally too - which is the case that actually motivates minimumReleaseAgeExclude.
Kody Review CompleteGreat news! 🎉 Keep up the excellent work! 🚀 Kody Guide: Usage and ConfigurationInteracting with Kody
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
Closes LAB-1020.
Dependabot's repo-level security updates toggle survived the 2026-04-25 Renovate migration and kept opening PRs that pnpm 11's release-age quarantine rejects at
pnpm install --frozen-lockfile— born-red, every job (see run 30134160651:postcss@8.5.23, published 6 h before the run, inside the 24 h cutoff). This PR makes the policy explicit in-repo; the toggle flip and dead-PR closures happen at the repo-settings level alongside it.What changed
minimumReleaseAge: 1440pinned inpnpm-workspace.yaml. The effective window was pnpm 11.8.0's built-in default —1440in its bundled config defaults ("minimum-release-age": 24 * 60, // 1 day), confirmed empirically by the failing run's cutoff timestamps (exactly run-time − 24 h). CI policy no longer moves silently when the package manager bumps.securityjob.pnpm audit --audit-level=highexits 1 on main's lockfile today (the advisories postdate main's last CI run on 2026-07-26) — any PR would fail the security job regardless of its diff. Remediated with the repo's establishedoverridespattern: postcss ≥8.5.18, brace-expansion 2.x ≥2.1.3 / 5.x ≥5.0.8, js-yaml ≥4.3.0 <5, sharp ≥0.35.0, protobufjs ≥7.6.5 <8. New floors are major-bounded — an unbounded floor re-resolves to the newest match including new majors (protobufjs 8.x and js-yaml 5.x exist).brace-expansion@2.1.3— the 2.x backport of the GHSA-mh99 fix, published today, i.e. a genuine 0-day security fix inside the window (the exact latent failure LAB-1020 predicted). Scoped to the single version so every future release of the package still age-gates; removable after 2026-07-29.auditConfig.ignoreGhsas: [GHSA-mh99-v99m-4gvg]— advisory-metadata lag only. Its published range (<=5.0.7, patched5.0.8only) numerically swallows the whole 2.x line and doesn't yet list the 2.x/3.x backports released 2026-07-27/28. The fix is installed on every resolved line (2.1.3 / 5.0.8); remove the ignore when the advisory adds the 2.x patched range.Window reconciliation (pnpm 1440 vs Renovate)
minimumReleaseAge: "5 days"in the shared preset): arrive ≥5 days after publish → always clear the 24 h pnpm window. A pnpm window longer than 5 days would red routine PRs; not introduced.vulnerabilityAlerts.minimumReleaseAge: "0 days"): may arrive same-day and red for up to 24 h — accepted trade-off. The 24 h quarantine defends against the exact attack class where the "fix" release is itself the compromise (Shai-Hulud-style); worst case is one manual rebase after the window, and a version-scopedminimumReleaseAgeExclude(as done here for brace-expansion) is the documented escape hatch when a same-day fix can't wait.@cachekit-io/*deps in this lockfile are workspacelink:entries (never fetched from the registry — this repo publishes them), and thecachekit-core 0.4.0bump is a Cargo dependency, outside pnpm's jurisdiction entirely. No exclusion needed.Verification
pnpm install --frozen-lockfileon the refreshed lockfile: passes the supply-chain policy check (533 entries) under the pinned window.pnpm audit --prod --audit-level=high→ exit 0;pnpm audit --audit-level=high→ exit 0 (1 ignored, documented above; remaining moderate is uuid <11.1.1 — patched version is a major bump, left for Renovate).tsc --noEmit✓, unit tests 546 passed / 13 failed — all 13 areMODULE_NOT_FOUNDon the native NAPI binding (no Rust toolchain on the agent box); CI builds the crate and covers those lanes.overridesverified present in the refreshedpnpm-lock.yaml(the LAB-211 silent-drop regression check).Summary by CodeRabbit
Bug Fixes
Documentation