包管理器需要全局钩子
Package Managers need global hooks

原始链接: https://captnemo.in/blog/2026/06/17/package-managers-need-hooks/

为了应对软件生态系统中日益增长的安全威胁,作者主张从根本上改变包管理器处理安全问题的方式。作者认为,不应再依赖代理注册表、Shell 包装器或中间人(MITM)拦截等脆弱的外部解决方案,而应由每个包管理器实现“全局钩子”(global hooks)。 目前的依赖冷却期和威胁情报策略等安全措施,往往是作为特定管理器内部的独立功能来实现的。作者认为,这些应当成为一个通用、原生钩子系统的实现细节,而非孤立功能。与本地包钩子不同,这些全局钩子会根据用户的全局配置,在包生命周期的各个阶段(如安装前或构建前)运行。 通过支持全局钩子,包管理器可以原生集成威胁情报、恶意软件扫描和安全策略,而无需公司构建额外且昂贵的基础设施。这种方法能够统一各生态系统(从 NPM 到 AUR 助手)的安全工作,使开发者无需为每种工具重复构建防御体系,即可保障各自的开发环境。作者呼吁社区优先向包管理器维护者提出原生全局钩子支持的需求。

Hacker News 最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 包管理器需要全局钩子 (captnemo.in) 5 点积分,evakhoury 1 小时前 | 隐藏 | 过往 | 收藏 | 讨论 帮助 | 准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文

This post is an expansion of what I wrote on r/archlinux as a proposal for AUR helpers. It is a call for every package manager to add support for global hooks.

The packaging ecosystems that we all rely on have been under constant attacks. The most interesting countermeasures currently are: Dependency Cooldowns, and Dependency Policies. A third interesting one is Homebrew’s cooldown which is a 1 day wait before they automatically bump a package from Python/NPM ecosystems.

In addition, almost every security vendor now has a package management “firewall” offering (Socket, Datadog, Safedep for eg). The various ways this can work is:

  1. Registry mode, where you can point your package manager at a local registry and it proxies requests, blocking access wherever it deems fit.
  2. Shell wrapper, where you alias your package manager and it intercepts your commands. Shell aliases are a very weak security boundary.
  3. MITM mode, where you configure it as a HTTPS Proxy and it intercepts your network traffic.

I don’t like any of these. All of the above depend heavily on either the Registry APIs, or the command schema. I also don’t like mechanisms that require any additional infra (such as a hosted pass-through registry that scans stuff), since it is additional infrastructure only accessible to companies and not individual developers.

My radical package-manager idea is this: every package manager should support global hooks. Cooldowns and Policies are just implementation details that a decent hook system should already allow you to do. What I mean by a global hook is: Code configured globally that runs before various stages in your package manager’s workflow. This is different from “local package hooks” - package-specific code that runs during/before/after your package gets installed.

I built a Dependency Policy proof-of-concept using the StepSecurity OSS Feed and pnpm’s hook system. Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed. Unfortunately:

  • pnpm’s hooks are on a per-workspace basis. This means you can’t run them for global installs, or configure them globally.
  • NPM does not support hooks.
  • Yarn has a hook API that yarn plugins can use, but I’m not sure if you can configure it globally.

But moving across to other package managers, the same system can help us deal with problems. An AUR helper can add hook-scripts, and you can configure your own threat-feed or malware scanner as a hook in the PreClone or PreBuild stage. More importantly - a hook doesn’t have to be a package, and it should be treated as global configuration.

We shouldn’t have to reinvent every defensive feature in every package manager. Ask your package manager to support global hooks instead:

Published on June 17, 2026
联系我们 contact @ memedata.com