PFM-ISSUE-34453 - github-actions: correct the mitigation's rationale (the prefix drop is an npm regression) - #164
Merged
Kaltenbach merged 1 commit intoAug 14, 2026
Conversation
…- the prefix drop is an npm regression
Wording and documentation only. No predicate, exit code or control flow changes;
bats stays 74/74 and no test asserts the prose.
A probe on a runner and locally (cplace-paw-fe PR #188, one-package fixture)
measured the prefix drop as npm-version-dependent, and in the direction nobody
had assumed:
npm 10.2.4 (node 18.19.1 - what every pipeline pins today)
un-normalized entry, no mitigation -> installs, served BY THE PROXY;
the rewrite preserves the registry's path prefix
npm 11.3.0 (developer machines; any runner on node 24)
un-normalized entry, no mitigation -> E404, prefix dropped
So it is a regression in newer npm, not an old bug since fixed. Nothing is
failing in CI today, and everything un-normalized fails the moment runners move
to node 24 - which makes this work a prerequisite for that migration rather than
a cleanup after it.
And replace-registry-host=never fetches those entries from the registry the
lockfile names, outside the proxy, on BOTH versions (proxy fetches: 0). On npm 11
that buys compatibility; on npm 10 it buys nothing and is the only reason traffic
leaves the proxy.
The advisory therefore stopped claiming "they install today only because
use-npmrc sets replace-registry-host=never" - false on the npm every runner
currently uses, and about to be replicated to ~41 repositories. design.md's
"broken today" is struck through and corrected with the measurements; the
use-npmrc comment, the README and the overview carry the same qualifier.
The removal criterion is unchanged, but its reason is: the flag comes out when
no lockfile reports foreign entries because it then has nothing to act on, not
because removing it would otherwise break something.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 14, 2026
Kaltenbach
added a commit
that referenced
this pull request
Aug 14, 2026
…d URLs onto the JFrog npm proxy (release/25.3) (#165) ## What this is Branch 2 of 7 for PFM-ISSUE-34453. Normalizes this branch's `package-lock.json` `resolved` URLs onto the JFrog npm proxy, and adds the same lockfile tooling and PR guard. **The tooling is byte-identical to the seed ([#163](#163), merged) — verified, not asserted:** ``` sha1(tools/scripts/lockfile/* + pr-checks.yml + use-npmrc/action.yml + .prettierignore) = f28f73029d4cb426 ``` Same on all seven branches. So the only thing needing review here is the lockfile commit, and that is machine-checked. The substantive review happened on #163. > **Note on the digest.** `release/25.2` currently reads `4aa3bcb389875d53` because > [#164](#164) — a wording-only correction to the advisory > message and the docs — is still open. These six already carry it. Merging #164 closes the gap; nothing else differs. ## Two commits 1. **Tooling**, copied verbatim from the seed. 2. **The normalized lockfile alone.** Its parent *is* the baseline, so the invariant is provable by construction: `./tools/scripts/lockfile/check-lockfile.sh --baseline HEAD~1`. ## Evidence - **171** entries rewritten, **+4788** bytes (262061 → 266849), **342** changed lines, **0** outside a `"resolved"` line - `grep -c registry.npmjs.org package-lock.json` → **0** (542 entries total) - `check-lockfile.sh --baseline HEAD~1` exits 0: graph identical to the baseline, exactly one registry prefix - bats **74/74** and shellcheck clean, both in CI via `pr-checks.yml` ## Why this matters now The prefix-drop that motivates this is a **regression in newer npm**, measured 2026-08-14: npm 10.2.4 — which every pipeline pins today via node 18.19.1 — rewrites correctly and resolves through the proxy, while npm 11.3.0 drops the registry's path prefix and fails with an `E404` masked as `***`. So nothing is failing in CI today, and everything un-normalized fails the moment runners move to node 24. This is a prerequisite for that migration, not a cleanup after it. Known limitation, same as #163: the guard **reports but cannot block** until PFM-ISSUE-34465 (Rule Sets enforcement) lands.
Kaltenbach
added a commit
that referenced
this pull request
Aug 14, 2026
…d URLs onto the JFrog npm proxy (release/25.4) (#166) ## What this is Branch 3 of 7 for PFM-ISSUE-34453. Normalizes this branch's `package-lock.json` `resolved` URLs onto the JFrog npm proxy, and adds the same lockfile tooling and PR guard. **The tooling is byte-identical to the seed ([#163](#163), merged) — verified, not asserted:** ``` sha1(tools/scripts/lockfile/* + pr-checks.yml + use-npmrc/action.yml + .prettierignore) = f28f73029d4cb426 ``` Same on all seven branches. So the only thing needing review here is the lockfile commit, and that is machine-checked. The substantive review happened on #163. > **Note on the digest.** `release/25.2` currently reads `4aa3bcb389875d53` because > [#164](#164) — a wording-only correction to the advisory > message and the docs — is still open. These six already carry it. Merging #164 closes the gap; nothing else differs. ## Two commits 1. **Tooling**, copied verbatim from the seed. 2. **The normalized lockfile alone.** Its parent *is* the baseline, so the invariant is provable by construction: `./tools/scripts/lockfile/check-lockfile.sh --baseline HEAD~1`. ## Evidence - **171** entries rewritten, **+4788** bytes (262061 → 266849), **342** changed lines, **0** outside a `"resolved"` line - `grep -c registry.npmjs.org package-lock.json` → **0** (542 entries total) - `check-lockfile.sh --baseline HEAD~1` exits 0: graph identical to the baseline, exactly one registry prefix - bats **74/74** and shellcheck clean, both in CI via `pr-checks.yml` ## Why this matters now The prefix-drop that motivates this is a **regression in newer npm**, measured 2026-08-14: npm 10.2.4 — which every pipeline pins today via node 18.19.1 — rewrites correctly and resolves through the proxy, while npm 11.3.0 drops the registry's path prefix and fails with an `E404` masked as `***`. So nothing is failing in CI today, and everything un-normalized fails the moment runners move to node 24. This is a prerequisite for that migration, not a cleanup after it. Known limitation, same as #163: the guard **reports but cannot block** until PFM-ISSUE-34465 (Rule Sets enforcement) lands.
Kaltenbach
added a commit
that referenced
this pull request
Aug 14, 2026
…d URLs onto the JFrog npm proxy (release/26.1) (#167) ## What this is Branch 4 of 7 for PFM-ISSUE-34453. Normalizes this branch's `package-lock.json` `resolved` URLs onto the JFrog npm proxy, and adds the same lockfile tooling and PR guard. **The tooling is byte-identical to the seed ([#163](#163), merged) — verified, not asserted:** ``` sha1(tools/scripts/lockfile/* + pr-checks.yml + use-npmrc/action.yml + .prettierignore) = f28f73029d4cb426 ``` Same on all seven branches. So the only thing needing review here is the lockfile commit, and that is machine-checked. The substantive review happened on #163. > **Note on the digest.** `release/25.2` currently reads `4aa3bcb389875d53` because > [#164](#164) — a wording-only correction to the advisory > message and the docs — is still open. These six already carry it. Merging #164 closes the gap; nothing else differs. ## Two commits 1. **Tooling**, copied verbatim from the seed. 2. **The normalized lockfile alone.** Its parent *is* the baseline, so the invariant is provable by construction: `./tools/scripts/lockfile/check-lockfile.sh --baseline HEAD~1`. ## Evidence - **171** entries rewritten, **+4788** bytes (270244 → 275032), **342** changed lines, **0** outside a `"resolved"` line - `grep -c registry.npmjs.org package-lock.json` → **0** (558 entries total) - `check-lockfile.sh --baseline HEAD~1` exits 0: graph identical to the baseline, exactly one registry prefix - bats **74/74** and shellcheck clean, both in CI via `pr-checks.yml` ## Why this matters now The prefix-drop that motivates this is a **regression in newer npm**, measured 2026-08-14: npm 10.2.4 — which every pipeline pins today via node 18.19.1 — rewrites correctly and resolves through the proxy, while npm 11.3.0 drops the registry's path prefix and fails with an `E404` masked as `***`. So nothing is failing in CI today, and everything un-normalized fails the moment runners move to node 24. This is a prerequisite for that migration, not a cleanup after it. Known limitation, same as #163: the guard **reports but cannot block** until PFM-ISSUE-34465 (Rule Sets enforcement) lands.
Kaltenbach
added a commit
that referenced
this pull request
Aug 14, 2026
…d URLs onto the JFrog npm proxy (release/26.2) (#168) ## What this is Branch 5 of 7 for PFM-ISSUE-34453. Normalizes this branch's `package-lock.json` `resolved` URLs onto the JFrog npm proxy, and adds the same lockfile tooling and PR guard. **The tooling is byte-identical to the seed ([#163](#163), merged) — verified, not asserted:** ``` sha1(tools/scripts/lockfile/* + pr-checks.yml + use-npmrc/action.yml + .prettierignore) = f28f73029d4cb426 ``` Same on all seven branches. So the only thing needing review here is the lockfile commit, and that is machine-checked. The substantive review happened on #163. > **Note on the digest.** `release/25.2` currently reads `4aa3bcb389875d53` because > [#164](#164) — a wording-only correction to the advisory > message and the docs — is still open. These six already carry it. Merging #164 closes the gap; nothing else differs. ## Two commits 1. **Tooling**, copied verbatim from the seed. 2. **The normalized lockfile alone.** Its parent *is* the baseline, so the invariant is provable by construction: `./tools/scripts/lockfile/check-lockfile.sh --baseline HEAD~1`. ## Evidence - **171** entries rewritten, **+4788** bytes (270244 → 275032), **342** changed lines, **0** outside a `"resolved"` line - `grep -c registry.npmjs.org package-lock.json` → **0** (558 entries total) - `check-lockfile.sh --baseline HEAD~1` exits 0: graph identical to the baseline, exactly one registry prefix - bats **74/74** and shellcheck clean, both in CI via `pr-checks.yml` ## Why this matters now The prefix-drop that motivates this is a **regression in newer npm**, measured 2026-08-14: npm 10.2.4 — which every pipeline pins today via node 18.19.1 — rewrites correctly and resolves through the proxy, while npm 11.3.0 drops the registry's path prefix and fails with an `E404` masked as `***`. So nothing is failing in CI today, and everything un-normalized fails the moment runners move to node 24. This is a prerequisite for that migration, not a cleanup after it. Known limitation, same as #163: the guard **reports but cannot block** until PFM-ISSUE-34465 (Rule Sets enforcement) lands.
Kaltenbach
added a commit
that referenced
this pull request
Aug 14, 2026
…d URLs onto the JFrog npm proxy (release/26.3) (#169) ## What this is Branch 6 of 7 for PFM-ISSUE-34453. Normalizes this branch's `package-lock.json` `resolved` URLs onto the JFrog npm proxy, and adds the same lockfile tooling and PR guard. **The tooling is byte-identical to the seed ([#163](#163), merged) — verified, not asserted:** ``` sha1(tools/scripts/lockfile/* + pr-checks.yml + use-npmrc/action.yml + .prettierignore) = f28f73029d4cb426 ``` Same on all seven branches. So the only thing needing review here is the lockfile commit, and that is machine-checked. The substantive review happened on #163. > **Note on the digest.** `release/25.2` currently reads `4aa3bcb389875d53` because > [#164](#164) — a wording-only correction to the advisory > message and the docs — is still open. These six already carry it. Merging #164 closes the gap; nothing else differs. ## Two commits 1. **Tooling**, copied verbatim from the seed. 2. **The normalized lockfile alone.** Its parent *is* the baseline, so the invariant is provable by construction: `./tools/scripts/lockfile/check-lockfile.sh --baseline HEAD~1`. ## Evidence - **171** entries rewritten, **+4788** bytes (270244 → 275032), **342** changed lines, **0** outside a `"resolved"` line - `grep -c registry.npmjs.org package-lock.json` → **0** (558 entries total) - `check-lockfile.sh --baseline HEAD~1` exits 0: graph identical to the baseline, exactly one registry prefix - bats **74/74** and shellcheck clean, both in CI via `pr-checks.yml` ## Why this matters now The prefix-drop that motivates this is a **regression in newer npm**, measured 2026-08-14: npm 10.2.4 — which every pipeline pins today via node 18.19.1 — rewrites correctly and resolves through the proxy, while npm 11.3.0 drops the registry's path prefix and fails with an `E404` masked as `***`. So nothing is failing in CI today, and everything un-normalized fails the moment runners move to node 24. This is a prerequisite for that migration, not a cleanup after it. Known limitation, same as #163: the guard **reports but cannot block** until PFM-ISSUE-34465 (Rule Sets enforcement) lands.
Kaltenbach
added a commit
that referenced
this pull request
Aug 14, 2026
…d URLs onto the JFrog npm proxy (master) (#170) ## What this is Branch 7 of 7 for PFM-ISSUE-34453. Normalizes this branch's `package-lock.json` `resolved` URLs onto the JFrog npm proxy, and adds the same lockfile tooling and PR guard. **The tooling is byte-identical to the seed ([#163](#163), merged) — verified, not asserted:** ``` sha1(tools/scripts/lockfile/* + pr-checks.yml + use-npmrc/action.yml + .prettierignore) = f28f73029d4cb426 ``` Same on all seven branches. So the only thing needing review here is the lockfile commit, and that is machine-checked. The substantive review happened on #163. > **Note on the digest.** `release/25.2` currently reads `4aa3bcb389875d53` because > [#164](#164) — a wording-only correction to the advisory > message and the docs — is still open. These six already carry it. Merging #164 closes the gap; nothing else differs. ## Two commits 1. **Tooling**, copied verbatim from the seed. 2. **The normalized lockfile alone.** Its parent *is* the baseline, so the invariant is provable by construction: `./tools/scripts/lockfile/check-lockfile.sh --baseline HEAD~1`. ## Evidence - **171** entries rewritten, **+4788** bytes (270244 → 275032), **342** changed lines, **0** outside a `"resolved"` line - `grep -c registry.npmjs.org package-lock.json` → **0** (558 entries total) - `check-lockfile.sh --baseline HEAD~1` exits 0: graph identical to the baseline, exactly one registry prefix - bats **74/74** and shellcheck clean, both in CI via `pr-checks.yml` ## Why this matters now The prefix-drop that motivates this is a **regression in newer npm**, measured 2026-08-14: npm 10.2.4 — which every pipeline pins today via node 18.19.1 — rewrites correctly and resolves through the proxy, while npm 11.3.0 drops the registry's path prefix and fails with an `E404` masked as `***`. So nothing is failing in CI today, and everything un-normalized fails the moment runners move to node 24. This is a prerequisite for that migration, not a cleanup after it. Known limitation, same as #163: the guard **reports but cannot block** until PFM-ISSUE-34465 (Rule Sets enforcement) lands.
This was referenced Aug 14, 2026
Open
Open
Open
Open
Open
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Wording and documentation only — no predicate, exit code or control flow changed. bats stays 74/74, shellcheck
clean, and no test asserts the prose.
Why
A probe on a runner and locally (closed PR cplace-paw-fe#188, one-package fixture proven installable through the
proxy) measured the prefix drop as npm-version-dependent, and in the opposite direction to what the docs assume:
E404It is a regression in newer npm, not an old bug since fixed. Nothing is failing in CI today; everything
un-normalized fails the moment runners move to node 24 — so this work is a prerequisite for the Node 24 migration
rather than a cleanup after it.
Separately,
replace-registry-host=neverfetches those entries from the registry the lockfile names, outside theproxy, on both versions (proxy fetches: 0). On npm 11 that buys compatibility; on npm 10 it buys nothing and is the
sole reason traffic leaves the proxy.
What changes
warn-foreign-registry.sh— the::warningand job summary stop claiming entries "install today only becauseuse-npmrcsetsreplace-registry-host=never". That is false on the npm every runner currently uses, and thistext is about to be replicated to ~41 repositories.
use-npmrc/action.yml— the comment at the mitigation records both versions and what the flag costs.design.md— "they are broken today" struck through and corrected with the measurements, the surface tablequalified, and the removal criterion's reason restated: the flag comes out when no lockfile reports foreign
entries because it then has nothing to act on — not because removing it would otherwise break something.
README.md,overview.md,overview.html— same qualifier.Verification
bats tools/scripts/lockfile/74/74 ·shellcheck -xclean · the advisory still exits 0 and reports 14 oncplace-paw-fe's
release/25.2lockfile, unchanged except for the message text.This precedes replicating the toolchain to the six remaining branches, so the corrected text ships once rather than
seven times.