npm ci fails with EALLOWREMOTE: six package-lock.json entries resolve to ms-feed-*.pkgs.visualstudio.com instead of registry.npmjs.org

[sosyz]

English

What happened

A fresh npm ci on main fails when npm is configured with allow-remote=none (the hardened supply-chain setting):

npm error code EALLOWREMOTE
npm error Fetching packages of type "remote" have been disabled
npm error Refusing to fetch "@xterm/xterm@https://ms-feed-2.pkgs.visualstudio.com/1es-public/_packaging/npm-public/npm/registry/@xterm/xterm/-/xterm-6.0.0.tgz"

The root cause is in package-lock.json: 6 of the 1027 resolved entries point at Microsoft-internal Azure DevOps feeds (ms-feed-{2,12,17,25}.pkgs.visualstudio.com) instead of registry.npmjs.org, presumably because the lockfile was regenerated behind a corporate registry mirror at some point. npm classifies these non-registry tarball URLs as "remote" dependencies and refuses them under allow-remote=none.

The affected entries are:

Package	Resolved host	Integrity
@dnd-kit/accessibility@3.1.1	ms-feed-25.pkgs.visualstudio.com	sha1
@dnd-kit/core@6.3.1	ms-feed-12.pkgs.visualstudio.com	sha1
@dnd-kit/sortable@10.0.0	ms-feed-12.pkgs.visualstudio.com	sha1
@dnd-kit/utilities@3.2.2	ms-feed-17.pkgs.visualstudio.com	sha1
@xterm/addon-fit@0.11.0	ms-feed-2.pkgs.visualstudio.com	sha1
@xterm/xterm@6.0.0	ms-feed-2.pkgs.visualstudio.com	sha1

Beyond the install failure, these entries are undesirable for two more reasons:

1. They carry sha1 integrity values instead of sha512, weakening lockfile integrity verification for exactly these 6 packages — relevant to the supply-chain baseline tracked in security: track the supply-chain security baseline #2207.
2. They make every contributor's install depend on Microsoft-internal feed hosts that are not guaranteed to be reachable or to exist long-term.

I verified that all 6 versions exist on the official registry and that the official tarballs are byte-identical to what the lockfile pins (the sha1 of each registry.npmjs.org tarball matches the lockfile's sha1 exactly), so the fix is a pure metadata rewrite with no dependency change:

• rewrite resolved to the corresponding https://registry.npmjs.org/... URL
• upgrade integrity to the official sha512 value

I have this 12-line lockfile patch ready and can open a PR if the approach sounds right.

How to reproduce

1. npm config set allow-remote none (or any environment where remote-type fetches are disabled)
2. git clone https://github.com/apache/maka && cd maka
3. npm ci → fails with EALLOWREMOTE on @xterm/xterm

Environment

• Maka commit: 98bdd6cf8
• OS: macOS (Darwin 25.5.0)
• Surface: build/install tooling (affects all surfaces)
• Node.js: v24.18.0

Logs, screenshots, or additional context

Verification method: curl each tarball from registry.npmjs.org, then openssl dgst -sha1 -binary | base64, and compare against the lockfile's sha1 — all 6 match. The remaining 1021 resolved entries already point at registry.npmjs.org.

中文

问题描述

在 npm 配置了 allow-remote=none（收紧的供应链安全设置）的环境下，main 分支全新执行 npm ci 会直接失败：

npm error code EALLOWREMOTE
npm error Fetching packages of type "remote" have been disabled
npm error Refusing to fetch "@xterm/xterm@https://ms-feed-2.pkgs.visualstudio.com/1es-public/_packaging/npm-public/npm/registry/@xterm/xterm/-/xterm-6.0.0.tgz"

根因在 package-lock.json：1027 个带 URL 的条目中有 6 个的 resolved 指向微软内部的 Azure DevOps feed（ms-feed-{2,12,17,25}.pkgs.visualstudio.com）而不是 registry.npmjs.org，推测是 lockfile 曾在企业镜像源环境下重新生成所致。npm 会把这类非 registry 的 tarball URL 归类为 "remote" 依赖，在 allow-remote=none 下拒绝下载。

受影响的 6 个条目：

包	Resolved 主机	Integrity
@dnd-kit/accessibility@3.1.1	ms-feed-25.pkgs.visualstudio.com	sha1
@dnd-kit/core@6.3.1	ms-feed-12.pkgs.visualstudio.com	sha1
@dnd-kit/sortable@10.0.0	ms-feed-12.pkgs.visualstudio.com	sha1
@dnd-kit/utilities@3.2.2	ms-feed-17.pkgs.visualstudio.com	sha1
@xterm/addon-fit@0.11.0	ms-feed-2.pkgs.visualstudio.com	sha1
@xterm/xterm@6.0.0	ms-feed-2.pkgs.visualstudio.com	sha1

除了安装失败之外，这些条目还有两个额外问题：

1. 它们的 integrity 是 sha1 而不是 sha512，恰好让这 6 个包的 lockfile 完整性校验强度被削弱——与 security: track the supply-chain security baseline #2207 跟踪的供应链安全基线相关。
2. 它们让每个贡献者的安装都依赖微软内部 feed 主机，其可达性与长期存在均无保证。

我已验证这 6 个版本在官方 registry 上全部存在，且官方 tarball 与 lockfile 锁定的内容逐字节一致（每个 registry.npmjs.org tarball 的 sha1 与 lockfile 记录的 sha1 完全相同），因此修复只是纯元数据改写，不涉及任何依赖变更：

• 将 resolved 改写为对应的 https://registry.npmjs.org/... 地址
• 将 integrity 升级为官方的 sha512 值

这个 12 行的 lockfile 补丁我已经准备好，如果方案没问题我可以直接提 PR。

复现步骤

1. npm config set allow-remote none（或任何禁用 remote 类型下载的环境）
2. git clone https://github.com/apache/maka && cd maka
3. npm ci → 在 @xterm/xterm 上报 EALLOWREMOTE 失败

环境

• Maka commit：98bdd6cf8
• 操作系统：macOS（Darwin 25.5.0）
• Surface：构建/安装工具链（影响所有 surface）
• Node.js：v24.18.0

日志与补充信息

验证方法：从 registry.npmjs.org 逐个 curl 下载 tarball，openssl dgst -sha1 -binary | base64 计算哈希，与 lockfile 的 sha1 对比——6 个全部一致。其余 1021 个 resolved 条目本来就指向 registry.npmjs.org。