Skip to content

fix(remediation): name the package that moves in a within-range refresh - #1313

Merged
sonukapoor merged 2 commits into
mainfrom
bugfix/issue-1291-within-range-command-names-child
Oct 11, 2026
Merged

sonukapoor merged 2 commits into
mainfrom
bugfix/issue-1291-within-range-command-names-child

Conversation

@sonukapoor

Copy link
Copy Markdown
Collaborator

A within-range refresh means the parent already allows a safe version of the vulnerable child, so the parent stays where it is and the child is what has to move. The command named the parent, which achieves nothing once the parent is already at its newest allowed version, because npm then has no reason to re-resolve its subtree.

Measured against a real install of @actions/glob@0.5.1, which declares minimatch: ^3.0.4, with minimatch@3.1.2 pinned in the lockfile: npm update @actions/glob left it at 3.1.2, and npm update minimatch moved it to 3.1.5.

The target still records the parent in package with the child on childPackage and childTargetVersion, so the reason text and the version separation from #1152 are unchanged. Only the emitted command differs.

Five existing assertions across three test files changed, because each asserted a command that does not move the package it names. The assertions that actually guard #1152, no warning marker and no child version rendered as a parent upgrade, are separate lines and still pass.

Verified on a 397-package npm monorepo: exactly one of its nine fix targets changed, from npm update @actions/glob to npm update minimatch. The other eight name packages that genuinely move and are byte-identical.

Refs #1291. This covers the npm case. The original report on that issue was pnpm, where the printed command already named the child and still moved nothing, so that half is a different mechanism and stays open.

A within-range refresh means the parent already allows a safe version of the
vulnerable child, so the parent stays where it is and the child is what has to
move. The command named the parent, which achieves nothing when the parent is
already at its newest allowed version, because npm then has no reason to
re-resolve its subtree.

Measured against a real install of @actions/glob@0.5.1, which declares
minimatch ^3.0.4, with minimatch 3.1.2 pinned in the lockfile:
npm update @actions/glob left minimatch at 3.1.2, and npm update minimatch
moved it to 3.1.5.

The target still records the parent in `package` with the child on
`childPackage` and `childTargetVersion`, so the reason text and the #1152
version separation are unchanged. Only the emitted command differs.

Refs #1291
@sonukapoor
sonukapoor force-pushed the bugfix/issue-1291-within-range-command-names-child branch from 27bf5ad to 1debf49 Compare October 11, 2026 15:52
@sonukapoor
sonukapoor merged commit ae90743 into main Oct 11, 2026
6 checks passed
@sonukapoor
sonukapoor deleted the bugfix/issue-1291-within-range-command-names-child branch October 11, 2026 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant