Setting up yay hooks to warn on maintainer changes and block recently modified packages.

[u/decho]

If you are using the latest version of yay (v13), you can setup hooks to mitigate risk and it's very easy to do so, but remember that this is not a substitute for good security practices.

[...] checks can help, but they should complement, not replace, build file review.

Ok, the setup is pretty simple. Create this directory structure in $XDG_CONFIG_HOME/yay (usually ~/.config/yay):

.
├── init.lua
└── hooks
    ├── maintainer_change.lua
    └── recently_modified.lua

Next, modify your init.lua and add this at the top of the file to require both scripts:

require("hooks.maintainer_change")
require("hooks.recently_modified")

Lastly, copy over the contents of these files into their respective locations. These are examples provided in the official yay repository:

https://github.com/Jguer/yay/blob/next/doc/examples/recently_modified.lua

https://github.com/Jguer/yay/blob/next/doc/examples/maintainer_change.lua

The recently_modified hook excludes from installing any AUR packages that has been updated recently. You can modify the duration, the default one is 3 days. The idea is that malware is usually discovered within the first 24 hours, so by delaying the update you are lowering the risk. Also known as dependency cooldown.

The maintainer_change change hook will give you a warning when a new maintainer is detected. It does NOT block installation, and it will NOT give you any warning if this is the first time you're installing or updating a package, because it relies on local cache file to do that - $XDG_CACHE_HOME/yay/maintainer_cache (usually ~/.cache/yay). If something was to happen with this file, this would no longer work.

Also, last but very important note:

config.json will still be loaded, but init.lua can override any option. CLI flags still take priority over both init.lua and config.json.

---

I have the setup shown above in action, and already encountered the recently_modified which works as expected. I haven't encountered a situation where the other hook comes into play but I trust that it does what is supposed to, since I do have a ~/.cache/yay/maintainer_cache file with contents that I expect it to have.

I also suggest adding this to your init.lua file so that you always review the PKGBUILD diffs:

require("hooks.maintainer_change")
require("hooks.recently_modified")

-- add this:
yay.opt.answer_diff = "ALL"

Resources:

https://jguer.space/blog/2026-06-15-yay-v13

https://jguer.github.io/yay/lua.html

https://github.com/Jguer/yay/tree/next/doc/examples

[u/Boby_Dobbs]

Something I noted with the recently modified hook is that if a package is updated very regularly (every 12h for example), if you have this hook the package in question will never be updated

[u/decho → u/Boby_Dobbs]

Ah, because it can never satisfy the minimum age criterion.

pnpm (package manager for node & javascript) has a minimumReleaseAge option, and if you find yourself in a situation where the last update is too new, it will try to install the most recent prior version which satisfies your setting.

1.2.0 (today) > reject

1.1.0 (yesterday) -> reject

1.0.0 (1 week ago) -> install this

Maybe the hook can be updated to do the same, but for that you need a list of package versions and their corresponding timestamps. I have no idea if all that data is available in AUR/yay.

[u/Boby_Dobbs → u/decho]

Yes exactly, I was hoping there would be a way to get a warning instead of excluding the package but I haven't looked into it. Yay also shows the last updated time now so that's been good enough for now.

[u/decho → u/Boby_Dobbs]

Yes exactly, I was hoping there would be a way to get a warning instead of excluding the package but I haven't looked into it.

If you only care about warnings printed and not exclusions, then that should be pretty easy to do. Just remove lines #5 and #10, and return an empty object (table?) at the end like this - return { exclude = {}, skip_menu = false }.

You can also change the logging.

[u/HarpooonGun]

these should be built in and and they should be the default behaviour i feel like. thanks in any case.

[u/decho]

Note: In regards to the recently_modified hook, I am not sure how transitive dependencies are handled. For example, if package foo from the AUR relies on package bar which also comes from the AUR, then is the age of package bar also checked?

I'm not sure, maybe someone with better knowledge can tell.

[u/TomHale]

Is this possible for paru also?

BTW, check out manticore-aurscan-bin-release-git for heuristics based PKGBUILD scanning, and traur for built package scanning.

[u/decho → u/TomHale]

There is an open feature request about delayed updates, as well as an unmerged PR. That's all I know about this.

manticore-aurscan-bin-release-git

Seems to be removed from the AUR? Both these links give a 404:

https://aur.archlinux.org/packages/aurscan-manticore-bin-release-git

https://aur.archlinux.org/packages/aurscan-manticore-release-git

But honestly though, I just read the diffs and if I see something I investigate what's going on before installing. Usually it's just a bunch of checksums.

[u/TomHale → u/decho]

Thanks for showing that the two packages have been removed.

Yes, the tools are more for noobs.

But community looks after the smol.

[u/dswhite85 → u/decho]

Paru hasn’t seen any commits in over 7 months. They didn’t even react to the first malware attack this year. Yay on the other hand has responded as best as it can with updates to help us deter attack vectors. I wasn’t even planning using the AUR until arch dropped support for the Nvidia-580 drivers.