When installing softwares on arch Linux, first searching for official packages provided by Arch Linux maintainers, then official installation methods approved by authors of the software, or AURs which do the installation in the exact way as the authors of the software describe.
A search on the default installation method of Firefox and librewolf package on arch Linux is listed below.
If AUR is required to install a package, note that AURs are not trusted by default because not all AURs are not maintained by trusted users. Always check the source file and the installation method documented in PKGBUILD. Don't do the installation until EVERY line in the PKGBUILD is reasonable.
ETA: According to a Reddit post linked elsewhere in this thread, the payload was a binary file downloaded by a python script in the repository. It has been uploaded to VirusTotal, but downloading requires a premium subscription according to their docs: https://www.virustotal.com/gui/file/d9f0df8da6d66aaae024bdca...
One could go even further and list all new commits, making it super easy for the user to check them. Maybe even integrate an LLM to help? Maybe commits from non long-time contributors could be flagged?
There has to be a way to help users programmatically review updates to their AUR packages. Even if most of them won't spend the time.
AUR clients already show you the diff if you update a package, but note that this were completely new packages anyway, uploaded 2 days ago, so that doesn't really apply here.
LLMs are useless for reviewing if something is malicious, their false-positive rates would be way to high. And even ignoring that you'd have to hide the LLMs code from the attacker or he can just check if his package is detected as malicious and modify it until it isn't. Not something open source projects are keen on doing.
The program I use for AUR (Rua) still displays exactly what you're about to build (as a git diff), before you build it, even if it's the first time/release. I'd assume all the other "AUR managers" would work the same way?
This particular issue is with a binary (i.e. pre-built) package, normally in Arch it's expected from an AUR package that you will build it yourself and most if not all packagers prompt you to review and or edit the PKGBUILD before it does anything.
Basically you could spot something suspicious in a source package, not so much in a binary package.
But, maybe it would be best not to have “yay” available. Using something like AUR without reading the package build files is… pretty bad, right? And it is bad for the community, because if there is a convention of doing that sort of thing, it makes the AUR a good target for attacking.
Even if you're using an immutable distro, your KDE Plasma session can get hijacked if you simply use the built in wizard to install 3rd party desktop widgets, which is a right-click + single-click away on any Plasma destkop.
Also anyone who wants to try "Gaming on Linux" needs bleeding edge kernel which is Arch's default setup compared to other distros.
The "CachyOS" page was deleted[1], and replaced with a redirect to the Arch Linux page. But CachyOS is not mentioned anywhere on that page, nor on the "List of Linux distributions § Arch Linux-based" page.
[1]: https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...
I love Arch Linux, but please...
(Arch Linux is already "fast" (depends on what you install for your DE, if any) and customizable.)
1) do you want an intermediary between you and the upstream? for example, to patch out telemetry
2) is it important that what you're using continues to work the same way so you can focus on your actual work?
No answer to either is consequence-free, e.g. for 1), see the Debian SSH patch event, or for 2), if the answer is "it doesn't work", then that kinda forces one's hand.
Then had to use something 'officially' supported for a while, then did some Debian derivative live-distro running from USB/in RAM because of HW-problems, and settled for CachyOS when new (old) HW arrived.
I update maybe once a month at the most, more likely every two monts, because I don't give a shit. With the exception of FF, or maybe some nicer Kernel, for eBPF and scheduler-stuff.
That's reviewing changes in a few config files, after having read up about them at Archs & CachyOS sites. Maybe five minutes max, opening a few relevant tabs. (If necessary at all, which often isn't the case.)
Starting Pacman. Downloads instantly, even if several GB. Decompresses and installs stuff. Maybe two to three minutes. Reboot. 20 seconds. Plasma is back.
Clicking FF. Back with all its tabs. Maybe two to three seconds. Maybe uBO blocks a few more secs sometimes, while updating lists.
After intentionally having killed it with -9 in preparation before reboot.
Cleaning Pacman's package-cache and btrfs-snapshots because The only way is Fooorwaaard!
( https://www.youtube.com/watch?v=e_tVzx_PIH8 Daxon ft. Numa - The Only Way (Extended Mix) [COLDHARBOUR RECORDINGS] 7mins, 7secs )
Letting btrfs rebalance in the background.
Opening other stuff, on other virtual desktops, being exactly where and how I left it, thanks to working session-mgmt.
Feels very convenient to me, in opposition to most of the other 'mainstream stuff'.
Maybe the memes have a core of truth to them? For ppl who know what they do?
Cachy, Cachy, Caramba, Yay, Yay!
Personally I've been running Arch on my work machine for a few years now with very few issues. I'm not even very consistent with updates, and probably run them about once every 3 weeks on average. I have only had to manually intervene on a handful of occasions.
I like it a lot because everything is always up-to-date. I don't face any issues with unsupported versions for tools like I have with Debian in the past. The rolling release model also saves me the pain of doing a "hard" OS upgrade, which often come with issues.
Eventually, I got more busy and had less time to tinker, so I migrated to Ubuntu LTS, which has some small warts, but has needed practically null babysitting compared to Arch. I was surprised when the Arch memes resurfaced this year, but that's the only growth I've seen. None of my Linux-savvy peers use Arch, BTW.
At least this guy has been using it as a daily driver (at home and at work) for at least fifteen years.
There is a reason Ubuntu is usually the first distro new Linux users go to. For almost a decade now, installing a feature-complete Ubuntu setup is not much more difficult than reimaging Windows.
I switched away from Arch (to Ubuntu) as a sort of side effect of switching computers a couple years ago (desktop->laptop, though Ubuntu would “bring the batteries along” more conveniently). Ubuntu is fine I guess, but I really miss the stability of rolling release and the user-friendliness of not having too many built in programs.
[1]https://web.archive.org/web/20250718140411/https://aur.archl...
IIRC, the post was just a single paragraph, praising how they “found” the zen-browser-patched-bin package on the AUR and how much it helped them.
[0]: https://www.reddit.com/r/archlinux/comments/1m30py8/aur_is_s...
My impression is that the malice was spotted timely, and not many people were affected. Which is a pretty good thing!
This makes me nervous. I guess it’s time to do some audits.
All decent AUR helpers (which arch developers advise against using anyway) force you to read through the packaging script and confirm that you understand it and are fine with what's about to be executed.
It's no more of an issue than someone posting a malware script into e.g. the wiki. Much less obscure than malware in npm or anything like that.
Yes, the AUR is user-provided content. Yes, system administrators are responsible for being aware of what they’re installing. You can find many comments from me on this page discussing that.
An attacker being detected using an official service hosted by Archlinux for user-managed packages to push malware is still noteworthy.
Running random binaries on your computer uploaded by some anonymous dude has to be the equivalent of buying heart medicine on craigslist. And because Arch is so barebones to begin with the AUR is very popular, you see a lot of arch users using it.
Not a single enterprise distro even reacts within that timeframe. OVAL advisories are weeks, sometimes months later.
As long as you don't have a virtualization approach similar to QubesOS, any linux distro will not fix this problem. Because that's not how separation of concerns works in the POSIX system. You need to have separate users for each and every program to isolate them, and that is practically unfeasible.
AUR helpers make reviewing changes to AUR packages a trivial matter that takes about 2 minutes of my life per month. In exchange I get easy access to software that isn't packaged for Ubuntu and probably never will be, because building debs and going through the process of upstreaming them is roughly comparable to getting a PhD (if anyone is even interested in your debs, which they probably won't be).
Pretty much every browser that isn't Firefox including Chrome, VS Code, most proprietary software like Slack, Zoom, Spotify, many vpn clients and password managers, a lot of them seemingly not published by the companies in question.
All of those ancillary password, vpn or security related products who aren't going to be in the main repo because they have proprietary elements and also rely on random people seems particularly bad. And there's a lot of software in that category.
Yes, proprietary software has to be installed separately, but for things like cloud password managers you're already putting your trust someplace else. You're also not likely to be hit by out of these flyby attacks, because the stuff people want is popular and has people watching it constantly and reputable people maintaining it. These patch/fix packages are suspicious looking and probably didn't have a single person touch them.
That's what Flatpak is for. If you must install crappy proprietary software, at least get an official package from the developer.
Most aren't, but it's trivial to review changes to packages (all good AUR helpers show the diff on upgrades, an 99% of time the changes are hash and version, nothing else).
So you only need to check the package once, which the documentation reminds you to do about fifty times. Otherwise — play stupid games, win stupid prizes.
If the package has any popularity at all, you will get lots of paranoid users who will eat you alive and report to Arch maintainers right away if you do anything suspicious, try to link a binary from some weird website instead of the upstream URL, or even just omit the GPG signature verification key when it's available.
and official repo does not have enough packages to run arch :\ I don't want to go back to ubuntu
It'd be nice to test it with a sample of aur package/malware.
PS. Regarding downloading files from internet, every self-update tool does that nowadays, it becomes more common because of apple/others stores policies. I created a few remote control tools and it is very very difficult to caught them, and I am not even a professional malware researcher. Things they do is beyond understanding of average superuser
How are they supposed to do that when you give them no information as to what the malware does?
More interesting questions are:
- Who was the uploader? A packager? For how long?
- Do they maintain other packages?
- What steps can be taken to ensure that a similar problem doesn't happen in future?
The AUR is arch's repository of untrusted user maintained read-the-source-before-installing packages. There's really not much that can be done to prevent similar issues in the future... because the whole purpose of the AUR is to allow random people to upload packages.
Arch doesn't ship with any way to install AUR packages other than downloading the tarball and building them locally. Tools for installing the packages usually force you to read the PKGBUILD that controls the build process (including getting sources) before letting you build the packages. I.e. the reasonable steps have already been taken.
Edit: firefox-patch-bin was first submitted to the AUR 2025-07-16 21:33 (UTC), so less than two days before removal.
I mean... ... if this was a malicious actor who is to say they don't have 15 aliases on 5 linux distros
With that comes the same warning as downloading random stuff from the internet and executing it, you need to carefully review everything before running/installing it, as you're basically doing a fancy version of "curl | bash" when using the AUR.
The malware operator could have done anything with that access... There's no way for the maintainers to know what was done on any given infected machine.
Also, an attacker may leave no traces by simply dumping the payload to /tmp.
Assuming the malware doesn't clean up after itself, `pacman -Q firefox-patch-bin librewolf-fix-bin zen-browser-patched-bin` would tell you if they are installed... but if it did clean up after itself... how are the maintainers supposed to know what steps were taken to clean up given that it's a rat that could be running different steps on different computers...
That said, if you did, yeah being hacked is scary and I feel for you.
My desktop OS is much less of a concern now, so I mostly use macOS. It provides a decent shell and otherwise stays out of my way. I use Windows for gaming.
They have to be installed via "pacman -U package_file"
Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package.
VirusTotal's API is free.
- https://docs.virustotal.com/docs/api-scripts-and-client-libr... - https://docs.virustotal.com/docs/please-give-me-an-api-key - https://docs.virustotal.com/docs/consumption-quotas-handled
Since it is end users who are doing the upload and virus scan check, there won't be a consumption quota issue with VirusToal.
Lastly, "pacman -U" should flag failed VirusTotal scans to Arch Security.
Arch's pacman and Flathub's flatpak package managers should be the last line of defence when installing untrusted packages by end users.
But more importantly this is a terrible idea in regards to privacy/infosec. I do not want packages I build and install myself to be uploaded to a 3rd party website.
And for what benefit? 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR.
To ensure reproducible / clean builds, I thought makepkg would always be run in a sandbox/chroot environment. The damage done would be localised to that sandbox.
> this is a terrible idea in regards to privacy/infosec.
Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs.
> 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR
Its too late then. People are already affected.
No, makepkg doesn’t run in a sandbox. The system tries to stop you from running it as root, but otherwise all validation of the trustworthiness of the pkgbuild and any sandboxing of the build process are left up to the user. This is part of why pacman, the 1st party package manager, does not fetch from the AUR.
Likewise, it would be generally against the Arch ethos to have the default behavior of the package manager interact with a 3rd party service. If a user wants that action, they’d need to perform it themselves.
makepkg runs in a fakeroot environment, but this is not a security barrier. There is also support for building inside systemd containers, offering at least limited security, but most AUR helpers don't use that yet.
> Ok. Devs could setup an option to pacman -U which allows it to bypass VT for privacy sensitive people. This just puts the onus on you to not ensure you aren't installing malware. The default Arch user should still be protected while allowing for your privacy needs.
You mistake the target group of Arch Linux. Users are expected to read the documentation and to know what they're doing. Protecting users from themselves at the expense of those who know what they're doing is not what Arch is about.
> Its too late then. People are already affected.
That doesn't make sense, it's too late for people if new malware isn't detected by VirusTotal as well.
Goes against the very nature of the distro. I very rarely see assumed defaults in Arch, and they are almost always opt-in. Mind you, you need community provided helpers to automate AUR building, its that barebones and I'm sure there are people who manually build / use custom scripts to build every package.
Pacman cannot be used to download, compile, or install AUR packages. You need the PKGBUILD file and use "makepkg -si" at the very least. If you want AUR packages, you'd install a package manager (in this context referred to as AUR helper) like "yay" that supports both official and unofficial (i.e. AUR) packages. FWIW AUR helpers are not even official packages, not even "yay" which is a popular one. You need to go out of your way to install "yay" (although it is one command away before, i.e. very easy).
TL;DR: Pacman does not download, compile, or install packages from the AUR, nor does it resolve their dependencies. "makepkg -si" builds and installs a package based on the PKGBUILD file, or use an AUR helper that overcomes the limitations of "makepkg". AUR helpers make it easy to install AUR (i.e. unofficial) packages.
AFAIK, VirusTotal only flags known malware/viruses, any new/"looks-to-be-new" stuff wouldn't be flagged until they've picked it up, and once someone would have picked it up, it should be removed from the AUR anyways. So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless.
This is where your and my intentions differ. I don't want the average Arch user to be infected when it can be prevented because the malware is known about.
Me neither, my argument would be that VirusTotal won't stop the initial users from getting infected, so not good enough in my mind.
