ci(renovate): freeze the version line of pnpm.overrides security pins #56

Merged

ullrich merged 1 commit from ci/renovate-freeze-override-pins into main

2026-07-30 11:31:51 +00:00

ullrich commented

2026-07-30 11:15:13 +00:00

Owner

Stops the #35/#36 class of change: Renovate proposing — and auto-merging — version-line jumps on entries that exist as CVE floors rather than as dependencies.

Why these PRs are wrong by construction

An override entry is not a dependency. The key says which range is vulnerable; the value is the minimum patched version inside the range its consumers expect. Renovate cannot know that, so it offers "latest". Three examples from one week:

PR	change	problem
#44	`path-to-regexp <0.1.13` → `8.4.2`	`express@4.22.2` needs the 0.1.x API; 8.x is an incompatible router, and E2E broke
#35	`path-to-regexp <0.1.13` → `0.2.5`	no advisory required leaving 0.1.x; auto-merged itself and changed what express resolves to
#36	`shell-quote <1.8.4` → `1.10.0`	same shape, queued next

#35 is why this is a rule and not more labels

#52 tagged these PRs security-pin. That reads well and gates nothing — so the auto-merge rule landed a minor bump on a security floor while the PR sat there correctly labelled. Documentation is not a control, and I should have paired the label with this rule at the time instead of deferring it.

Patch stays enabled, deliberately

A patch inside the pinned line is exactly the right update for a floor (picomatch 4.0.4 → 4.0.5) and cannot move consumers onto a different API. Only minor and major are frozen.

The cost, stated in the config

If a future advisory can only be satisfied by crossing a minor or major — undici 7 going EOL, say — Renovate will not raise it and it has to be done by hand. That is the right trade while osvVulnerabilityAlerts is unconfigured, because none of these PRs are advisory-driven today; they are version-currency noise aimed at security entries. Once OSV alerts are wired up, advisory-driven bumps arrive through that path instead, which is the correct source for changing a floor.

Verified

Computed effective enabled/automerge per scenario with later-wins ordering, rather than reading rule order:

#44 path-to-regexp -> 8.x      enabled=false
#35 path-to-regexp -> 0.2.5    enabled=false
#36 shell-quote -> 1.10.0      enabled=false
picomatch 4.0.4 -> 4.0.5       enabled=true   automerge=true
ordinary dep minor             enabled=true   automerge=true
ordinary dep major             enabled=true   automerge=false

Follow-on

Once this lands, #36, #44, #46 and #47 are all updates Renovate no longer considers, so they should be closed. #35 already merged — worth deciding separately whether to revert it, since its cd-apps deploy was still queued as of a few minutes ago and production is on the pre-#35 image.

Stops the #35/#36 class of change: Renovate proposing — and auto-merging — version-line jumps on entries that exist as CVE floors rather than as dependencies. ## Why these PRs are wrong by construction An override entry is **not a dependency**. The key says which range is vulnerable; the value is the minimum patched version *inside the range its consumers expect*. Renovate cannot know that, so it offers "latest". Three examples from one week: | PR | change | problem | |---|---|---| | #44 | `path-to-regexp <0.1.13` → `8.4.2` | `express@4.22.2` needs the 0.1.x API; 8.x is an incompatible router, and E2E broke | | #35 | `path-to-regexp <0.1.13` → `0.2.5` | no advisory required leaving 0.1.x; **auto-merged itself** and changed what express resolves to | | #36 | `shell-quote <1.8.4` → `1.10.0` | same shape, queued next | ## #35 is why this is a rule and not more labels #52 tagged these PRs `security-pin`. That reads well and **gates nothing** — so the auto-merge rule landed a minor bump on a security floor while the PR sat there correctly labelled. Documentation is not a control, and I should have paired the label with this rule at the time instead of deferring it. ## Patch stays enabled, deliberately A patch inside the pinned line is exactly the right update for a floor (`picomatch 4.0.4 → 4.0.5`) and cannot move consumers onto a different API. Only minor and major are frozen. ## The cost, stated in the config If a future advisory can only be satisfied by crossing a minor or major — undici 7 going EOL, say — Renovate will not raise it and it has to be done by hand. That is the right trade while `osvVulnerabilityAlerts` is unconfigured, because **none of these PRs are advisory-driven today**; they are version-currency noise aimed at security entries. Once OSV alerts are wired up, advisory-driven bumps arrive through that path instead, which is the correct source for changing a floor. ## Verified Computed effective `enabled`/`automerge` per scenario with later-wins ordering, rather than reading rule order: ``` #44 path-to-regexp -> 8.x enabled=false #35 path-to-regexp -> 0.2.5 enabled=false #36 shell-quote -> 1.10.0 enabled=false picomatch 4.0.4 -> 4.0.5 enabled=true automerge=true ordinary dep minor enabled=true automerge=true ordinary dep major enabled=true automerge=false ``` ## Follow-on Once this lands, #36, #44, #46 and #47 are all updates Renovate no longer considers, so they should be closed. #35 already merged — worth deciding separately whether to revert it, since its `cd-apps` deploy was still queued as of a few minutes ago and production is on the pre-#35 image.

ullrich added 1 commit

2026-07-30 11:15:14 +00:00

ci(renovate): freeze the version line of pnpm.overrides security pins

CI / Security Scan (pull_request) Successful in 1m4s

Details

CI / Dockerfile Package Check (pull_request) Successful in 2m7s

Details

CI / Checks (pull_request) Successful in 8m56s

Details

CI / Visual Tests (pull_request) Successful in 4m9s

Details

CI / Journal Image Smoke Test (pull_request) Successful in 4m24s

Details

CI / E2E Tests (pull_request) Failing after 11m45s

Details

dab47e1b14

Stops the #35/#36 class of change: Renovate proposing — and auto-merging —
version-line jumps on entries that exist as CVE floors rather than as
dependencies.

An override entry is not a dependency. The key says which range is vulnerable
and the value is the minimum patched version *inside the range its consumers
expect*. Renovate has no way to know that, so it offers "latest". Three examples
from one week:

  #44  path-to-regexp <0.1.13 -> 8.4.2   express@4.22.2 needs the 0.1.x API;
                                         forcing 8.x substitutes an incompatible
                                         router, and E2E duly broke
  #35  path-to-regexp <0.1.13 -> 0.2.5   no advisory required leaving 0.1.x;
                                         auto-merged itself and changed what
                                         express resolves to
  #36  shell-quote <1.8.4    -> 1.10.0   same shape, queued next

#35 is why this is a rule and not more labels. #52 tagged these PRs
`security-pin`, which reads well and gates nothing, so the auto-merge rule landed
a minor bump on a security floor while the PR sat there correctly labelled.
Documentation is not a control.

Patch stays enabled deliberately. A patch inside the pinned line is exactly the
right update for a floor (picomatch 4.0.4 -> 4.0.5) and cannot move consumers
onto a different API.

The cost, stated in the config: if a future advisory can only be satisfied by
crossing a minor or major — undici 7 going EOL, say — Renovate will not raise it
and it has to be done by hand. That is the right trade while
`osvVulnerabilityAlerts` is unconfigured, because none of these PRs are
advisory-driven today; they are version-currency noise against security entries.

Verified by computing effective `enabled`/`automerge` per scenario with
later-wins ordering rather than reading rule order:

  #44 path-to-regexp -> 8.x      enabled=false
  #35 path-to-regexp -> 0.2.5    enabled=false
  #36 shell-quote -> 1.10.0      enabled=false
  picomatch 4.0.4 -> 4.0.5       enabled=true  automerge=true
  ordinary dep minor             enabled=true  automerge=true
  ordinary dep major             enabled=true  automerge=false

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X8hNxgYp777FRqYtVmQNaU