Official feed of AUR packages deleted for malware?

musdus · 2026-08-03 09:17:16

Hi all,

Since the June 2026 AUR incident, a few community detection tools (archcanary among them) maintain lists of known-malicious AUR package names so users can scan their systems.
Right now those lists come from a mix of:

- The HedgeDoc note from the June incident (manually maintained, not really meant as an ongoing feed)
- A third-party continuous scanner (aur-audit.wtako.net)
- Individually-reported packages — via the Arch Linux mailing lists (aur-general and similar), forum threads, and GitHub issues — hand-verified and merged by whoever maintains the tool (https://github.com/musqz/archcanary/blo … IBUTING.md)

--> That last one exists because there's no lighter-weight alternative — not because it's the ideal source.

Every time a TU deletes or orphans a package specifically for malicious content, that decision is already made; it's just not published anywhere a script can consume.

Would it be possible to expose that subset as a simple, dated, machine-readable list — package name, date, reason category ("malicious"/"policy violation") — whenever a package is removed for that reason? No writeups or CVE-style detail needed, just the bare fact. Tools could poll it instead of everyone re-deriving the same information from mailing-list threads and wiki notes independently.

Does something like this already exist that I'm just not aware of (an AUR deletion log, an RSS feed)?

Github project Archcanary
https://github.com/musqz/archcanary

:bird:

Last edited by musdus (2026-08-03 10:52:00)

Lone_Wolf · 2026-08-03 10:05:46

If such a list exists (which I doubt) it is not publicly available.

Moderator Note

Community Contributions
A place for true innovation. Share your own created utilities with the Arch community.

Unless you are involved in creating/maintaining the archcanary project, this is not the right board for such a post.

Moving to AUR Issues, Discussion & PKGBUILD Requests

musdus · 2026-08-03 10:55:11

Ha, fair — that's on me, I should've said that up front.

I'm the maintainer/developer of archcanary. Apologies for the confusion.

On "I doubt such a list exists" — totally fair reaction if you're picturing something official, because there isn't one.
None of the sources I listed claim Arch/AUR-blessed status.

> The HedgeDoc note from the June incident (manually maintained, not really meant as an ongoing feed)
> - A third-party continuous scanner (aur-audit.wtako.net)
> - Individually-reported packages — via the Arch Linux mailing lists (aur-general and similar), forum threads, and GitHub issues — hand-verified and merged by whoever > maintains the tool (https://github.com/musqz/archcanary/blo … IBUTING.md)

What actually backs archcanary's lists today is exactly the patchwork above : the June HedgeDoc note, aur-audit.wtako.net's independent scanning, and hand-verified community reports merged in by hand
(raw files here if useful: https://github.com/musqz/archcanary/tree/master/lists).

That patchwork is the actual point of my question, not a tangent: TUs already make the "malicious, not just abandoned" call every time they delete/orphan for cause — that judgment exists, it's just not exposed anywhere a script (or a person) can consume without re-deriving it from mailing-list threads and wiki notes by hand.

So the question still stands — does something like that already exist that I've missed? An AUR deletion log, an RSS/Atom feed, anything machine-readable?

Last edited by musdus (2026-08-03 10:55:27)

seth · 2026-08-03 12:24:07

maintain lists of known-malicious AUR package names so users can scan their systems

None of the recent incidents would have escaped an even superficial review of the PKGBUILD (the last one added an undocumented stripped elf binary and ran that w/o comment - yeah, sure… and just checking it for strings reveals it's probably writing a systemd service file)
I understand your request and intent and idea, but it follows a very dangerous mindset. Each and every PKGBUILD you've not vetted is not known to be non-malicious and must be considered dangerous until proven otherwise!

As for packages having been subject to the recent attacks they'll follow the pattern of being "maintained" by inactive accounts.
Eg. https://aur.archlinux.org/packages/meshcore-open-git *was* corrupted by https://aur.archlinux.org/account/mariannemoen

Lone_Wolf · 2026-08-04 11:25:42

Some comments about the software :

install.sh --system will only work if the user running it has sudo permission for rm, install , systemctl, sed , chmod, cp and probably some more I missed.

On my system that script will fail hard as my regular user only has sudo rights for a few commands .
A possible workaround is to put the parts needing root rights in separate scripts that are called with su - c /path/to/script .

install.sh installs things to be used with yay and paru but doesn't test if they are present .

musdus · 2026-08-05 06:21:36

Thanks for the feedback @Lone_wolf

I will have a look at it.

Thanks for testing...

musdus · 2026-08-05 09:09:35

Thanks for flagging this — both are live now.

For the sudo issue:
Instead of switching to su -c like you suggested, I went with consolidating everything into one script (lib/archcanary-root-install.sh)that install.sh calls via a single sudo bash ....
Reasoning: su -c needs the root password, and plenty of Arch installs never set one — so that would've broken more setups than it fixed.
This way install.sh --system only ever runs one thing under sudo, so instead of allowlisting ~20 individual commands, your sudoers just needs one line pointing at that script (added the exact syntax to the README). Tested it live on my own box, install + uninstall both clean.

Appreciate you taking the time to test — Let me know if you hit anything else.

youruser ALL=(root) /usr/bin/bash /path/to/archcanary/lib/archcanary-root-install.sh

https://github.com/musqz/archcanary#installation

Lone_Wolf · 2026-08-05 11:18:09

and plenty of Arch installs never set one

That means they effectively block root access which can be done but requires installation and configuring of sudo before booting the first time.
While possible I'd be surprised if more then a small minority used it.

The rule you propose seems a bit much , I'd probably use the local hostname instead of ALL . It's definitely a big improvement over the previous version though.

musdus · 2026-08-05 14:57:51

Changed ALL to local hostname.

Thanks for the feedback. much appreciated.

Arch Linux

#1 2026-08-03 09:17:16

Official feed of AUR packages deleted for malware?

#2 2026-08-03 10:05:46

Re: Official feed of AUR packages deleted for malware?

#3 2026-08-03 10:55:11

Re: Official feed of AUR packages deleted for malware?

#4 2026-08-03 12:24:07

Re: Official feed of AUR packages deleted for malware?

#5 2026-08-04 11:25:42

Re: Official feed of AUR packages deleted for malware?

#6 2026-08-05 06:21:36

Re: Official feed of AUR packages deleted for malware?

#7 2026-08-05 09:09:35

Re: Official feed of AUR packages deleted for malware?

#8 2026-08-05 11:18:09

Re: Official feed of AUR packages deleted for malware?

#9 2026-08-05 14:57:51

Re: Official feed of AUR packages deleted for malware?

Board footer