For example this tool got big during the last attacks - 2k+ stars on github … but zero updates for the latest incidents. They invite a “oh, all checkboxes green, I’m good” feeling for the current moment, that doesn’t necessarily translate into the future. Writing these tools requires more than a one time effort, but a long term commitment and short reaction times.
It’s great these tools exist, and the effort that go into them should be praised. They can be a valuable asset and provide additional feedback. But they will create a false sense of security if they become the sole source of inspection. They (currently) can’t replace eyes and brain when evaluating AUR packages.
I would go a step further and point out that most of these tools are also AUR packages that can be subject to the same issues as any other AUR package.
those tools (cscs’s last month and @made-lief 's now) to me were created for a specific time and place and situation and I couldn’t imagine using them past that. so not adopt exactly…but I do agree that some kind of aur CVE Checker, based in /extra, is a good idea for arch users.
From what I can gather, it appears the “bad actors” are trying to adopt AUR packages that haven’t been maintained in a while but maybe not listed as orphaned yet.
Traur only scans the packages and informs about information changes. It shows the trust level of the apps based on information that is gathered. The scanner needs only be minimal and is probably doing the job the developer wanted. Many of programs out there in use that are not actively developed. I use openbox which hasn’t had development in over ten years however its considered feature complete.
UPDATE.
I was not aware the original Author had Abandoned the project. I ended up removing traur myself. So please disregard the above information as it does not pertain to this particular situation
…and as @thefrog stated in the Traur thread, it scans AFTER the software has been installed, so any warnings are already one step behind any potential bad actors.
Sad to hear traur may be abandoned. While I seek to rely primarily on knowing where the software comes from and checking the AUR PKGBUILDs, it seemed like a good idea to have a “last check” in case something got by me. Much like Endeavour’s check to see if a reboot is recommended.
For your interest. Archcanary started with forking aur-malware-check.
What is archcanary?
Archcanary is a layered security detection stack for Arch Linux — scanning for malicious AUR packages, systemd/eBPF persistence, npm/bun cache poisoning, kernel module tampering, library injection, and more.
It started from lenucksi/aur-malware-check under the name aur-malware-check, originally focused on the June 2026 AUR supply-chain attack. As the tool grew to cover a much broader set of system checks — integrating a GUI frontend, automated systemd timers, and multiple detection layers — the scope outgrew the original name.
It’s great that someone creates these tools, and they massage out the current quirks and report “all green” in the end. The developer is happy, users are happy, but that is only a snapshot in time, which becomes the past.
With the reactionary nature of many of these tools they can’t be relied on when a new wave hits. Sure, someone may update it, fork it again, etc… but the first line of defense in early days and weeks is always the individual user reviews - and those reviews hitting the mailing list.
This is not judging the devs, but we all have lives with other responsibilities, and staying on top of the matter requires a serious commitment. Otherwise it puts other users at risk if the dev isn’t in it.
…