Hi Keon, Thanks for the excellent feedback!
You are absolutely right. While this specific campaign (atomic-lockfile, js-digest, etc.) focuses entirely on the JS ecosystem, running *any* language-specific package manager inside a post-install .install hook is a massive violation of Arch packaging guidelines and a huge security red flag. I have just updated the Gist to expand the behavioral heuristics. The script now flags any unauthorized invocations of Python (pip/pipx), Rust (cargo), PHP (composer), or Ruby (gem) inside the install hooks, alongside the existing JS package managers. Legitimate build() usage is unaffected, since those checks only apply to .install hooks. Thanks for helping make the tool more versatile against concurrent or future supply-chain vectors! Best regards, cmhacks Gist: https://gist.github.com/l33tm4st3r/f6895a62167bd3d83f298d27ffd46741 El dom, 14 jun 2026 a las 9:52, Keon Cachia (<[email protected]>) escribió: > > Is there a particular reason why this script only checks for JS package > managers? I am aware they are the most common when it comes to malicious > packages but, it was easy for me to add others such as Composer and > Cargo. > > Keon Cachia
