2026-08-17
每日一文 · 长文精读
npm 12 Released: Install Scripts off by Default as Registry Moves to Explicit Trust
npm 12 发布：安装脚本默认关闭，注册表转向显式信任
作者：Daniel Curtis · InfoQ 原文
摘要：npm 12 发布，默认关闭安装脚本，要求开发者显式允许。同时弃用绕过双因素认证的细粒度访问令牌。Git 和远程依赖也默认禁用。社区反应积极，但安全研究人员警告批准疲劳风险。
npm, the package manager maintained by GitHub and shipped with Node.js, has released npm 12, shipping with a set of security related default changes to npm install alongside the deprecation of granular access tokens that bypass two factor authentication.
由 GitHub 维护、随 Node.js 发布的包管理器 npm 已推出 npm 12，该版本对 npm install 进行了一系列与安全相关的默认更改，同时弃用了可绕过双因素认证的细粒度访问令牌。
npm 12 turns three install behaviours that previously ran automatically into ones developers explicitly opt into.
npm 12 将之前自动运行的三种安装行为转变为需要开发者显式选择加入。
The changes were first announced in June and have been available behind warnings since npm 11.16.0, so teams could prepare before upgrading.
这些更改于 6 月首次宣布，并从 npm 11.16.0 开始以警告形式提供，以便团队在升级前做好准备。
The headline change is that allowScripts now defaults to off.
最引人注目的变化是 allowScripts 现在默认关闭。
Dependency preinstall, install and postinstall scripts no longer run unless they are explicitly allowed in a project, and that includes implicit node-gyp builds for any package containing a binding.gyp file, even where no install script is declared.
依赖项的 preinstall、install 和 postinstall 脚本不再运行，除非在项目中显式允许，这包括对任何包含 binding.gyp 文件的包进行的隐式 node-gyp 构建，即使没有声明安装脚本也是如此。
prepare scripts from git, file and link dependencies are blocked in the same way.
来自 git、file 和 link 依赖项的 prepare 脚本也以相同方式被阻止。
Developers review what is pending, approve what they trust, and commit the resulting allowlist in package.json.
开发者审查待处理项，批准他们信任的项，并将生成的允许列表提交到 package.json 中。
The other two defaults target non registry sources.
另外两个默认设置针对非注册表源。
--allow-git now defaults to none, closing a code execution path where a Git dependency's own .npmrc could override the Git executable even with --ignore-scripts set, and --allow-remote defaults to none, blocking https tarball dependencies.
--allow-git 现在默认为 none，关闭了一条代码执行路径，即 Git 依赖项自身的 .npmrc 可能覆盖 Git 可执行文件，即使设置了 --ignore-scripts；--allow-remote 默认为 none，阻止 https tarball 依赖项。
The related --allow-file and --allow-directory flags are unchanged.
相关的 --allow-file 和 --allow-directory 标志保持不变。
GitHub's migration discussion recommends allowing what is already in the tree first, then tightening, and documents recipes for native modules, Cypress, Playwright, Puppeteer, Electron and Husky.
GitHub 的迁移讨论建议先允许树中已有的内容，然后收紧，并记录了针对原生模块、Cypress、Playwright、Puppeteer、Electron 和 Husky 的配方。
Global installs and npx cannot use approve-scripts and need the config instead, for example npm config set allow-scripts=canvas,sharp --location=user.
全局安装和 npx 无法使用 approve-scripts，需要改用配置，例如 npm config set allow-scripts=canvas,sharp --location=user。
Full details are in the docs for npm approve-scripts, npm deny-scripts and allow-scripts config.
完整细节在 npm approve-scripts、npm deny-scripts 和 allow-scripts 配置的文档中。
Commenters on the thread flagged that an existing ignore-scripts=true takes precedence and silently defeats the allowlist, and that newly installed packages create a chicken and egg problem, since npm approve-scripts reads from node_modules and errors with ENOMATCH if the package is not yet installed.
讨论串中的评论者指出，现有的 ignore-scripts=true 会优先并静默地使允许列表失效，而新安装的包会产生先有鸡还是先有蛋的问题，因为 npm approve-scripts 从 node_modules 读取，如果包尚未安装，则会报错 ENOMATCH。
Community reaction has been broadly supportive.
社区反应普遍支持。
The Hacker News thread drew 484 points and more than 200 comments, with atraac writing that: postinstall scripts should've been removed long time ago, it's the cancer of NPM packages.
Hacker News 讨论串获得了 484 分和超过 200 条评论，atraac 写道：postinstall 脚本早就该被移除，它是 NPM 包的毒瘤。
There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.
有太多深层嵌套、不受控制的 postinstall 脚本在你拉取东西时随机运行，这太疯狂了，我不知道怎么会有人认为这是个好主意。
Others were less convinced.
其他人则不那么信服。
gear54rus pointed to legitimate use cases such as patch-package, while cookiengineer argued the allowlist ‘has no scope’ and leaves it ‘unpredictable if any of your dependencies of dependencies needs a script’.
gear54rus 指出了像 patch-package 这样的合法用例，而 cookiengineer 则认为允许列表“没有范围”，使得“你的依赖项的依赖项是否需要脚本变得不可预测”。
Security researchers have raised approval fatigue as the bigger risk.
安全研究人员提出，批准疲劳是更大的风险。
Writing on OpenSourceMalware, one analyst noted that esbuild, sharp, core-js, puppeteer and bcrypt all rely on lifecycle scripts, and warned that repeated broken builds will turn deny by default into ‘a click-through prompt’, while pushing attacker activity onto surfaces with less visibility.
一位分析师在 OpenSourceMalware 上写道，esbuild、sharp、core-js、puppeteer 和 bcrypt 都依赖生命周期脚本，并警告说，反复的构建失败会将默认拒绝变成“一个点击通过的提示”，同时将攻击者活动推向可见性较低的表面。
JFrog reports the three vectors were involved in roughly 53% of malicious npm attacks observed in the past year.
JFrog 报告称，在过去一年观察到的恶意 npm 攻击中，这三个向量涉及约 53%。
npm is also the last major package manager to adopt these controls.
npm 也是最后一个采用这些控制措施的主要包管理器。
pnpm has offered install script allowlisting for years, and on cooldowns pnpm shipped minimumReleaseAge in 10.16, yarn added npmMinimalAgeGate in 4.10.0 and bun followed in 1.3, ahead of npm's own min-release-age in 11.10.0.
pnpm 多年来一直提供安装脚本允许列表功能，并在冷却期后于 10.16 版本中推出了 minimumReleaseAge，yarn 在 4.10.0 中添加了 npmMinimalAgeGate，bun 在 1.3 版本中跟进，均早于 npm 在 11.10.0 中自己的 min-release-age。
npm is the default package manager for Node.js and is maintained by GitHub.
npm 是 Node.js 的默认包管理器，由 GitHub 维护。
It hosts the largest software registry in the world, giving developers a command line client and registry to install, share and publish reusable JavaScript and TypeScript packages.
它托管着世界上最大的软件注册表，为开发者提供命令行客户端和注册表，用于安装、共享和发布可复用的 JavaScript 和 TypeScript 包。
As a foundational part of the wider Node.js ecosystem, npm is used across frontend and backend projects to manage dependencies, run scripts and distribute open-source code at scale.
作为更广泛的 Node.js 生态系统的基础部分，npm 被用于前端和后端项目，以管理依赖项、运行脚本和大规模分发开源代码。
阅读理解
1. What is the primary security change introduced in npm 12 regarding install scripts?
2. According to the article, what is a potential risk of the new allowlist approach raised by security researchers?
3. What issue did commenters on the discussion thread identify with the new allowlist system?