Update:
Archcanary v0.1.33 released — full-AUR false-positive pass
archcanary v0.1.33 is now on the AUR (archcanary) and tagged in the repo.
Most of this release came out of running archcanary’s PKGBUILD checks (–check-pkgbuild, and the yay/paru pre-build hooks) against every live package on the AUR — roughly 111,000 PKGBUILDs. Thanks to Andreas Reichel, who ran the scan and sent back the full hit list on 25 Aug. That turned up two things: a couple of genuine detection gaps, and several patterns firing on entirely legitimate packages. The false positives were the priority — a few of them weren’t just noise, the yay hook was hard-blocking the install.
False positives fixed
- ANSI colour output in printf. The hex/octal-escape check flagged any printf containing a \x or \0 escape, so a normal printf ‘\033[1m…’ bold/colour line tripped a WARNING on 246 AUR packages — and the yay hook aborted the build outright. It now only fires when an escape decodes to an actual command byte (a letter or digit), or when the printf output is piped into a shell.
- The Chrome extension-ID line. echo $key | base64 -d | sha256sum | head -c32 | tr 0-9a-f a-p — the standard snippet in dozens of browser-extension -bin packages — was read as … | sh and flagged, again with a hard abort in the yay hook. Pipe-to-shell detection is now properly word-anchored: | sha256sum, | grep bash, | pacman -S bash no longer count; | sh, | bash, | sudo bash still do.
- Commented-out lines. A trailing # sudo pacman -U --noconfirm ./pkg.tar.zst build note — common in hand-written PKGBUILDs — was matched as a real non-interactive pacman call (this was the EndeavourOS-forum timeshift report, against a years-old cached copy). Whole-line comments are now skipped by that check and several others (the aur@ self-propagation check, sudo/doas/pkexec, the MR/PR-patch check, base64-to-shell). 21 packages carrying a # push this + .SRCINFO to ssh://aur@… boilerplate comment are no longer flagged. Checks where a payload hidden in a comment is never legitimate — Tor/onion fetches, downloads into system paths, byte-assembled commands — still read comment text.
- Overly broad new rules, calibrated down. The sudo-in-build()/package() check went from ~500 hits to 121 once it stopped counting .install scriptlets (already root) and sudo -u someuser steps. The mutable-patch-URL check went from ~320 to 46 once patch URLs carrying a real checksum — already pinned by makepkg’s own verification — were excluded.
- One rule pulled. A pkgver-vs-source-URL version-mismatch check flagged 800+ packages at low precision (rolling heads/master tarballs, _pkgver/_commit URL variables, and versionless CDN links are all normal). Removed for now, parked for a rework in v0.1.34.
New detections
- sudo / doas / pkexec inside a PKGBUILD’s build() or package(). makepkg runs those functions as your user, so shelling out through sudo writes onto the live system instead of into the package directory — e.g. tarah runs sudo cp … /usr/bin. .install scriptlets (meant to run as root) and sudo -u are not flagged.
- An unchecksummed source= entry pointing at a forge merge-request or pull-request diff URL. That content can be force-pushed after you’ve reviewed it. A pinned hash, or a /commit/.patch URL, is fine and isn’t flagged. Example: freetype2-wps.
Both are in the yay hook too, as warnings rather than blocks.
Also
- Some of the yay hook’s Lua pattern anchors were dead code — yay 13 runs the hook under gopher-lua, which doesn’t support the %f frontier pattern they used. Rewritten so they actually match, with a lint test to
yay -Syu archcanary
archcanary --doctor