包管理器需要全局钩子

# 包管理器需要全局钩子 来源：https://captnemo.in/blog/2026/06/17/package-managers-need-hooks/ 2026年6月17日 本文是对我在r/archlinux（https://old.reddit.com/r/archlinux/comments/1u7t7mt/aur_megathread_all_discussion_on_it_goes_here/os532wt/）上提出的AUR辅助工具方案的扩展。我呼吁每个包管理器都应支持*全局钩子*。 我们所依赖的软件包生态系统一直遭受持续攻击。目前最有趣的应对措施包括：依赖冷却期（https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns）和依赖策略（https://github.com/composer/composer/issues/12786）。另一个有趣的方案是Homebrew的冷却机制，它在自动从Python/NPM生态系统升级包之前会等待一天（https://github.com/Homebrew/brew/pull/21919）。 此外，几乎所有安全厂商现在都提供包管理“防火墙”方案（例如Socket、Datadog、Safedep）。这些方案的实现方式包括： 1. 注册表模式：将包管理器指向本地注册表，由它代理请求并在认为必要时阻止访问。 2. Shell包装器：通过别名劫持包管理器命令，从而拦截操作。Shell别名是安全性很弱的边界。 3. 中间人模式：将其配置为HTTPS代理，拦截网络流量。 以上的方案我都不喜欢。它们都严重依赖注册表API或命令模式。我也不喜欢需要额外基础设施的机制（例如托管的透传注册表来扫描内容），因为这类基础设施只有公司才能使用，个人开发者无法触及。 我的激进包管理器构想是：**每个包管理器都应支持全局钩子**。冷却和策略只是优秀的钩子系统本应能够实现的实现细节。我所说的全局钩子是指：全局配置的代码，在包管理器工作流的各个阶段之前运行。这与“本地包钩子”（在包安装期间/之前/之后运行的包特定代码）不同。 我基于StepSecurity OSS Feed和pnpm的钩子系统构建了一个依赖策略概念验证（https://github.com/captn3m0/npm-sec-feed）。每次安装包时都会对照威胁源进行检查，如果发现恶意安装就会抛出异常。但问题是： - pnpm的钩子是按工作区配置的，这意味着无法对全局安装生效，也无法进行全局配置。 - NPM不支持钩子。 - Yarn有一个供yarn插件使用的钩子API，但我不确定能否全局配置。 但在其他包管理器中，同样的系统可以帮助我们解决问题。AUR辅助工具可以添加钩子脚本，你可以在`PreClone`或`PreBuild`阶段配置自己的威胁源或恶意软件扫描器。更重要的是——钩子不必是一个包，它应该被视为全局配置。 我们不必在每个包管理器中重新发明所有防御功能。请要求你的包管理器支持全局钩子： - pnpm的功能请求（https://github.com/pnpm/pnpm/issues/11882） - uv的相关问题（https://github.com/astral-sh/uv/issues/9346） - Paru已支持PreBuild钩子（https://github.com/Morganamilo/paru/blob/master/man/paru.conf.5#L382-L391） - yay的钩子系统已为`UpgradeSelect`事件（https://github.com/Jguer/yay/pull/2855）进行了升级，可以实现冷却期检查。这很容易扩展到威胁源。 - （欢迎在评论中补充更多） > 发布于2026年6月17日（https://captnemo.in//blog/2026/06/17/package-managers-need-hooks/）