The “Atomic Arch” campaign compromised over 1,500 AUR packages between June 10-12, targeting SSH keys and API tokens. If you updated via yay or paru during that window, you need to audit your local system.
I’ve built a client-side tool to help with this.
Local Processing: Your package list never leaves your browser. All comparisons are done client-side.
Live Data: It fetches the verified malicious list directly from the official Arch servers (md.archlinux.org) to ensure it’s always current. Zero Bloat: No trackers, no ads, no cookies. How to use:
- Run pacman -Qm
- Paste the output into the tool
Seems a bit extreme.
Most dipshits tend to go straight for the nuclear option so honestly checks out.
It’s a Windows user habit.
This dipshit (me) hasn’t reinstalled their OS since 2014. Not Arch btw.
But if my OS was affected by a supply attack like this, I wouldn’t trust the analysis on which packages were affected and which weren’t so I’d likely nuke and pave as all my and my family data is here.
I wouldn’t trust the analysis either; luckily most PKGBUILD scripts are quite short and simple. It would take significantly less effort to hand-audit every single file I’ve gotten from the AUR than it would to reinstall Arch.
As long as you’re using a slower release cycle, ie something like Debian, then you shouldn’t need to be concerned.
I think anyone riding the crest of the wave with Arch (& esp. the AUR) would likely be aware that things break, so, supply chain attacks are likely to be seen here quicker.
I honestly wouldn’t be surprised if PPAs had similar issues, but might take longer to be noticed.
Personally, I have a lot of Ansible building my stuff, so actually rebuilding things wouldn’t be an issue, but, would I then be installing everything with all the current latest malware…?
If your current system were affected by a supply attack, then you would reinstall your system too. I use Arch[1], BTW and did not reinstall the system.
1: Arch=EndeavourOS