Package Managers need global hooks

# Package Managers need global hooks Source: [https://captnemo.in/blog/2026/06/17/package-managers-need-hooks/](https://captnemo.in/blog/2026/06/17/package-managers-need-hooks/) 17 Jun 2026 This post is an expansion of what I wrote on[r/archlinux](https://old.reddit.com/r/archlinux/comments/1u7t7mt/aur_megathread_all_discussion_on_it_goes_here/os532wt/)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](https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns), and[Dependency Policies](https://github.com/composer/composer/issues/12786)\. A third interesting one is Homebrew’s cooldown which is a 1 day wait[before they automatically bump a package from Python/NPM ecosystems](https://github.com/Homebrew/brew/pull/21919)\. 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](https://github.com/captn3m0/npm-sec-feed)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: - [Feature request for pnpm](https://github.com/pnpm/pnpm/issues/11882) - [Relevant issue for uv](https://github.com/astral-sh/uv/issues/9346) - [Paru already supports a PreBuild hook](https://github.com/Morganamilo/paru/blob/master/man/paru.conf.5#L382-L391)\. - yay’s hook system[got an upgrade for an`UpgradeSelect`event](https://github.com/Jguer/yay/pull/2855)where you can do cooldown checks\. This should be extendable to threat\-feeds quite easily\. - \(Comment to add more here\)\. > Published on[June 17, 2026](https://captnemo.in//blog/2026/06/17/package-managers-need-hooks/)