> We strongly encourage users that may have installed one of these
packages […] to take the necessary
measures in order to ensure they were not compromised.
How are they supposed to do that when you give them no information as to what the malware does?
Per the Wayback Machine the username used was danikpapas. As far as Google and duckduckgo know these are the only packages theat username ever uploaded. Considering the purpose was crime it's likely that that username was "stolen" and the person using it on other sites wasn't the same as the one doing this...
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.
>Per the Wayback Machine the username used was danikpapas. As far as Google and duckduckgo know these are the only packages theat username ever uploaded.
I mean... ... if this was a malicious actor who is to say they don't have 15 aliases on 5 linux distros
They are/were AUR packages it seems, anyone can spend 2 minutes and upload essentially anything there, like npm and similar. It's not necessarily a "maintainer" per se, as like the people who manage the packages in the proper Arch repositories, but entirely separate.
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.
It says what the malware does, it's a remote access toolkit... It gives control of your machine to the malware operator.
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.
Announcements like this typically contain information that will help users identify if they were compromised, such as the name of files that are dropped or modified when the malware is initialized, startup entry names, etc. Obviously the person with remote access can get in and manually start doing things on individual machines, but that doesn't mean there aren't indicators present from the programmatic actions the malware took before that point or on machines that weren't manually accessed.
Expecting a complete malware analysis from maintainers is a tad too much. Their goal is to notify users as soon as possible, even if no other information about the malware is available.
Also, an attacker may leave no traces by simply dumping the payload to /tmp.
In addition to the point about "not being expected to do a full malware analysis"...
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...
This is really scary for those who manage multiple things. I'm considering running a factory reset on everything from my router to my Steam Deck and remote server.
As @lillylizard pointed out, it turns out that these are new packages, not comprised existing packages like I first thought.
Still, the nature of the hack is a Remote Execution, as you pointed out elsewhere, meaning the hacker could pull my router password from the password manager, or grab my SSH keys and log into whatever machine is listed in the known_hosts, or just mess with my Ebay account and the credit card saved on there. The hacker could in theory do literally anything I could do.
Whether or not SteamOS installed them is irrelevant. All the hacker would need is to compromise a machine that had some sort of remote access to other devices (ssh in this case, with some sort of keylogger to decrypt the private key).
You are not compromised unless you specifically installed one of these 3 packages on one of your machines:
- librewolf-fix-bin
- firefox-patch-bin
- zen-browser-patched-bin
The packages were only available for download for 3 days, and the only way you could have installed them is if you explicitly typed one of the package names into your terminal within those 3 days.
Did you do that? If no, then you are not compromised.
I had the regular librewolf-bin package installed on a couple of my machines. It took me a bit of time to note that librewolf-fix-bin is something separate.
And these packages are from AUR, they are not officially supported. AUR means Arch User Repository. You cannot even use Arch Linux's official package manager to install AUR packages either, you need an AUR helper ("makepkg" is sufficient though but it has limitations). These AUR helpers are not even official packages either. Not even yay: https://archlinux.org/packages/?sort=&q=yay.
I’m well aware. Arch isn’t my daily driver anymore, but I used it for many years before really committing to containerization.
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.
It's a remote access trojan. There is no acceptable way to be sure of removal short of full reinstalling every OS installed and reinstalling or rebuilding stuff in the Home dir from known good sources.
Comments below is from the perspective of an arch Linux user, not maintainer or authors of some software.
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.
This shouldn't reasonably be considered secure because it isn't altogether hard to obscure the nature of the attack until someone notices they are compromised.
The PKGBUILDs are not archived, but the package page does helpfully list its sources, one of which is https://github.com/danikpapas/zenbrowser-patch.git (same for all three packages). I would assume that's where the malware is, but I couldn't find an archive. Does https://www.gharchive.org/ keep this sort of data?
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...
Could there be programmatic ways to help users characterize the safety of the AUR packages they install? Perhaps a program that prints all URLs in the PKGBUILD and offers the option for the user to open them in the browser? Or which automatically shows a diff if a PKGBUILD is updated? Highlighting changes would make it easier for the user to determine if he should spend time exploring those changes for malware.
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.
PKGBUILDs are just bash scripts following a certain function and variable naming convention. Even if you could somehow parse it safely and extract the URLs of the 'source' array, any attacker can just simply put an obfuscated version of the malware URL into the build() function and download it there.
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.
> 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.
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?
As one commentor pointed out, in Arch it's the user's responsibility to review any AUR packages BEFORE installing them (and I say this as an Arch user and AUR package maintainer).
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.
yay is a package manager that has been made for AUR. yay is not the official package manager for Arch Linux, pacman is, and it does not support AUR. yay is not installed on Arch Linux by default, its official package manager, pacman, is. AUR is for unofficial 3rd party packages, i.e. "use at your own risk". It has always been the case.
Yes, it is "use at your own risk" but most arch users just install from it without giving it a second thought, because availability of packages in the AUR is the one thing Arch is good at.
> most arch users just install from it without giving it a second thought
I'm not sure that's true. Neither I nor most people I know who use Arch (granted, most of them are professional software developers) install software from the internet willy-nilly and without reviewing anything, if by AUR or "curl | bash", especially when on their main computers.
N=1 but I rarely install from AUR and I have been using Arch Linux for decades. Using "yay" is akin to doing "curl | sh". You should inspect the PKGBUILD at the very least, and I do not believe "most users" is correct.
Oh, and by the way, not sure how people miss these:
> Warning: AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
> Warning: AUR helpers are not supported by Arch Linux. You should become familiar with the manual build process in order to be prepared to troubleshoot problems.
"yay" is one of the most common AUR helpers, it requires two confirmations from what I counted. One of them is to inspect the PKGBUILD file, the other one is just to proceed.
Those users are going to learn some hard lessons, either in this incident or a future one.
Archlinux is a distro that’s designed for the user to control their own system, and the AUR is clear about what it is and the nature of the packages in it.
It's also good at being fairly simple and transparent, and having the only sane package format in existence (along with Alpine's apkbuild which is basically the same thing), but okay.
On one hand, the distro developers can’t really prevent people from, say, hitting their computers with a sledgehammer or something. So to some extent, the users have to be trusted.
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.
Oh, I thought it was a package from the repo. (I didn’t use any of those third party package managers, just stuck to manually doing everything when using the AUR, which was fine because I used it sparingly).
> 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.
I don't remember how yay works but paru (another AUR package manager) displays the pkgbuild file before it will install.
Nearly all distros have this problem when it comes to packaging and distributing 3rd party software.
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.
The current iteration of SteamOS (the one shipped on Steam Deck) is Arch based. So a lot of non-linux users got exposed to it as their first linux distro. Especially with all the emulation guides and other random guides for doing "advanced" stuff to your Steam Deck by dropping in the Arch-ish desktop.
Also anyone who wants to try "Gaming on Linux" needs bleeding edge kernel which is Arch's default setup compared to other distros.
This is a slight aside, but CachyOS is a great example of the failure of Wikipedia politics.
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.
It links to https://en.wikipedia.org/wiki/Arch_Linux#Derivatives which indeed lacks any mention of CachyOS. Luckily, Wikipedia is free to register, and you can just edit pages you feel like could be better. Seems like you found the perfect first edit to make for yourself :)
It's an endemic issue on wikipedia, and even editing wouldn't fix this one instance, since someone can (and demonstrably already has) remove whatever you add later on. The issue is wikipedias preference for "deletionism", removing perfectly correct information for no particularly good reason. It's especially pernicious when it comes to short articles, which tend to get deleted with impunity, and redirected to sections of articles, which later get renamed, destroying the link, or removed altogether. Nothing can be done by any individual to fix this issue, since it comes from a wikipedia wide policy, which unfortunately is not one of the things that "anyone can edit".
I agree with most of what you wrote, but unless you can demonstrate that someone actually added CachyOS to the "Arch Linux-based" on the "List of Linux distributions" page and it was later removed, I'm not sure how much it matters how Wikipedia generally works.
I have a long Wikipedia history, but that is not the point. There already was a CachyOS page, and it was removed. Why bother contributing stuff that will just be deleted again?
It might have been removed due to the editor's impression that CachyOS is not significantly different from Arch. With proof to the contrary the page may be restored.
There are a lot of derivative(I don't mean it in a negative way) distors out there, not sure if they all need pages.
Most moderated spaces remove content that doesn't fit the community, Wikipedia does take that to the extreme but I still prefer that than the opposite extreme.
But their differentiation is that to improve performance they compile all the packages with newer instruction sets as the target as well as enabling more optimizations like LTO. And some are even optimized with PGO.
I find it odd to call a specific Linux distribution blazingly fast.
Gentoo with make.conf (/etc/portage/make.conf[1]) having "CFLAGS="-O3 -march=native -flto"" means that Gentoo, a Linux distribution, is performant?
[1] It is not a good idea to build everything with LTO or PGO enabled because not all packages support LTO / PGO cleanly. Do it on the basis of per-package.
I've seen claims of decent speed improvements when using CachyOS, though I can't say I've ever hunted down solid confirmation. I'm a bit wary of the project because I would have to put a lot of trust in them since they're rebuilding everything themselves and could easily introduce malware somewhere in there. (But I've been scared of distros before only to have it pointed out to me that some very well respected people are involved, so I could be worrying for nothing here too)
Does Gentoo have binpkgs with these compileflags? With CachyOS you don't have to compile, because it's a rolling binary distro. Regarding your [1]: They do that, systemd(or parts of it) are unoptimized, for instance. They don't apply that stuff blindly, only where it works.
For me it feels blazingly fast, even on obsolete KabyLake Core-I5/7(t) forcibly clocked down to about 800Mhz most of the times :)
It fucking flies without much effort. On modern systems even more so. While being rock solid. Without any crashes. Even under Plasma. When I'm reading about bugfixes regarding crashes under Plasma I just shrug and think "Waddya talkin about?". That may be hardware dependent, though, because they are old Lenovo Thinkcentres(1Litre SFF M910q tiny) with excellent firmware.
Using btrfs, profile-sync-demon, zram(Yes. Even with 32GB Ram!). Suspend/Resume working every single time. No glitches, hick-ups, ever. So far. Since 10th of June, 2024.
Edit: Almost always some music out of yt doodling in some bg-tab, in oh-so-slow FF, without any clicks, stuttering, or other breaks.
No need for yt-dlp, mpv at all. Except for dl/saving stuff, sometimes. While FF is rarely under 100 tabs.
Good for you. The 'oh-so-slow' regarding FF was meant as satirical btw. With what I'm using it for, it doesn't lag. Maybe because of https://github.com/graysky2/profile-sync-daemon mostly, and some other fine-tunings, which make it not touching the filesystem over and over again. I really recommend PSD. Not even insane amounts of RAM, it usually takes about 4 to 5GB, rarely going to 8, then shrinking back a while after closing too much tabs. Imagine that!1!! It's all about some sysctl settings :-)
Sideberry (Tree-Style-Tabs like extension) was the ugliest offender there. Though that may have been me misconfiguring it. OTOH I didn't manage to find settings where it didn't do that, and still looked like I wanted it to. At that time, maybe a year ago, I've thought of it as potential 'instant ssd-killer'. Couldn't be bothered. Deinstalled.
Now FF has some basic version of vertical tabs by Mozilla itself. It suffices(for now).
Thanks, PSD looks interesting. I only have 8 GB RAM at the moment, I will see if my motherboard supports more (it should support 16 GB at the very least). After the RAM upgrade, I will probably use PSD. Or is there a way to specify how many RAM it can use?
As for tabs, I like the way Vivaldi does it and allows me to customize.
By "Not even insane amounts of RAM, it usually takes about 4 to 5GB, rarely going to 8, then shrinking back a while after closing too much tabs." I meant to say that this applies to the resident size in RAM of the whole browser, not what PSD does, or adds. That would be just what your browser profile is using 'on disk'. Peanuts, so to speak.
With only 8GB it's really hard to tell. It depends on your usage patterns.
First, regarding just PSD, it relies on RuntimeDirectorySize= of https://man.archlinux.org/man/logind.conf.5 which by default is limited to use up to 10% of system memory, but not statically reserved, only "on demand".
Which in turn relies on tmpfs which can use up to half of system RAM by default. Again, on demand only, not statically reserved.
However, I think these are the wrong knobs to turn :-)
PSD can make use of overlayfs, which saves a little bit of used RAM, and is faster to initially sync, but uses more disk space then. But not that much. Which can be further minimized by the number of kept profile backups, or not using backups at all.
Just keep your profile lean and mean, then there's less stuff to shuffle around.
Since your'e using Vivaldi, pointing you to wikipages how to make Firefox use less RAM seems pointless ;)
While it may seem insane to reserve already limited RAM for just another thing, these are worth it. If configured right. I used them, or their predecessors since olden times, when I've just had a Thinkpad T60p with some Centrino and only 4GB.
That made things better in general. Of course it's no silver bullet for everything, but it made the system less sluggish, and it took longer to slow down because of being 'swapped to death'.
From then on I continued to use stuff like that.
On a system with only 8GB, too. ZRAM in this case, because backing device like zswap was impossible, because the HDD blew. So I booted live from USB(2(Arrgh!)) and ran from RAM.
By means of AntiX, which btw. showed my the ways sysctls regarding swappiness, pressure stall information, and related stuff can totally change the behaviour of a system.
Even if it looks strange/ghettoish at first, which can be remastered away easily anyways, the devs really know how to get the most out of older systems with limited RAM and power, in interesting ways. Should be looked at, even if only for 'inspiration', technically.
For instance making things like Firefox shrink back, after having closed too much tabs.
And remaining usable, while doing so.
Anyway. Depending on what you do, 8GB only can go a looong way, if configured/used right.
IMO not using ZRAM/ZSWAP, sysctls for swappiness, PSI, etc. is wrong and wasteful.
An evaluation of what's best really depends on how one weighs different tradeoffs. For example, Debian and Arch are basically polar opposites in terms of two questions:
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.
There's also the significant caveat with 2 that it's only "continues to work the same way" until everything changes all at once because you now need to update to the next version of Debian.
The "everything changing all at once" thing is what eventually drove me to arch (as the most popular at the time rolling release distro - and more stable at the time than debian sid), I'd personally rather have smaller breaking changes more frequently. Though it's probably less painful now to update debian versions than it use to be because things generally work better without configuration than they used to.
This is just ignorant. I've been daily driving Linux since 2005. The majority of that time has been with Arch. Despite the memes, I've found it to be MORE stable than your typical Debian derivatives. It's funny to me that it took over a decade for people to come to the same realization.
You know? I did drive Arch daily for a few years, coming from NetBSD.
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!
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.
I'm hesitant to comment further seeing I've attracted the ire of some people with my comment, but anyway. I too used Arch out of curiosity about like ten years ago, during the first "Arch, BTW" memes, and found it too unstable, but that's expected from a rolling release: update too soon or too late, and something could break. I didn't mind, as it was a hobby.
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.
FWIW, the only breakage I've seen over the past 5 years is amdgpu bugging out on latest kernel releases, which is easily solved by running linux-lts.
I've had way more problems with Ubuntu trying to be convenient and bringing in lots of Windows-style automation that breaks more often than it works (and when that happens, you're really on your own since you have no idea how it's put together — just like in Windows).
Or even just bugs that were solved upstream ages ago (and have been available in every rolling-release distribution, including Debian testing/sid).
The current Arch installer suggests btrfs with snapper, so you get automatic snapshots pretty much out of the box (need to check one flag in installer), and can easily rollback if something breaks. Not something I needed, but it's there.
I can't imagine what kind of a problem I would personally have to encounter to make me utter such a sweeping generalization with this much confidence. :)
At least this guy has been using it as a daily driver (at home and at work) for at least fifteen years.
Well, Arch has (historically) been rather difficult to install from scratch, and requires a lot of Linux knowledge to get up-and-running as a daily driver. If one is installing it for the first time and misses something (which audio backend?), it can be rather frustrating down the line.
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.
It this recent? I thought “I use arch btw” was more of a thing… 5 or so years ago.
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.
Any clue what these packages were 'supposed' to do or why somebody might have installed them? Their PKGBUILD descriptions are copies of the respective browsers', not explaining the -patched part.
Looks like someone archived the page of firefox-patch-bin[1] and the only thing that stands out about the package itself is that it's supposedly the "Extended Support Release." Besides that it looks like it's depended on by 183 other packages/metapackages. While that seems more interesting, there isn't an archive of all of those packages.
These 183 packages depend on "firefox", and the malicious firefox-patch-bin had a provides=( 'firefox' ) clause in it. That's why they all get listed on that page. The provides clause is useful when you have multiple packages for the same thing with different names, for example -bin and -git versions.
I saw the ESR part - I assumed the author (mistakenly?) copied firefox-esr's description. As for the dependents, it seems the malware package provided `firefox`, meaning all dependencies on `firefox` can instead be fulfilled by `firefox-patch-bin`. Perhaps the idea was to fool package managers into showing it as one of the alternatives.
I wondered about the same thing. Not an answer, but my guess would be that it's just a new package and they hoped someone picked it up by accident?
In that case, it was patched with malware :)
I wonder how popular these packages were. Librewolf and Firefox sure are popular, so this sounds scary, but for example searching for "firefox-patch-bin aur" yields no results, aside from sites talking about how it contained malware.
My impression is that the malice was spotted timely, and not many people were affected. Which is a pretty good thing!
Why would it be? AUR is user generated content by definition, you're expected to read and understand every package before using it, which is repeated in documentation ad nauseam. They're very, very explicit about this and that you're on your own when using AUR.
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.
I guess we have very different takes on this; I wouldn't expect Slack or WhatsApp to publish security advisories if one of their users used them to spread malware among a tiny cohort of other users, which is about the right level of responsibility Arch places on itself (and it's very clear about this) w.r.t AUR.
I think you’re correct. I see a fundamental difference between services like slack and WhatsApp which provide messaging services and hosted platforms like the AUR where content is submitted and then republished on a site administered by the project.
it should be noted that these are different from the popular librewolf-bin (513 votes) and zen-browser-bin (176). with this in mind it's cool that these got identified only 2 days after being uploaded. I wonder if the reporter actually intended to install it or just reads the PKGBUILDS of new packages to be a good samaritan...
There's always been this security theater of people recommending arch because they "don't trust the companies" or Canonical or what have you but frankly I'm surprised this hasn't happened sooner. Well or maybe it has and we don't know.
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.
I agree, it's much better in Ubuntu land where you simply won't have the software at all, will shrug your shoulders and go on with your life.
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).
How exactly is Arch barebones? It basically ships with everything I need, more than most distros (Zed and Discord are good examples). I don't even need to use the AUR.
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.
Chrome is in the main repos as chromium. VS Code is the "code" package. I don't know what vpn clients you're referring to, but networkmanager is built-in and has support for openvpn and wireguard.
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.
Some of those packages (like Brave) are maintained by original developers, it depends on the package.
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.
i installed a lot of cra* from aur in the past, wouldn't be surprised if i got a malware somewhere. Strange thing, I don't think open snitch would even help in such situation..
and official repo does not have enough packages to run arch :\
I don't want to go back to ubuntu
I haven't taken a look at the malware, but it seems to download files from the Internet so it should have warned you to allow/deny the outbound connections.
It'd be nice to test it with a sample of aur package/malware.
it does, I am using it extensively (little snitch on mac, and open snitch on linux). My problem with it is that every new tool wants to connect to the internet and my terminal is the constant source of outbound connections. I try to review everything but the amount of tools and connections is overwhelming. It does limit the risk, but i do not trust my terminal and dev tools as usually i give them way too many permissions and any plugin or tool from AUR can contain 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
First of all, this is incorrect, the checking would have to happen _before_ even building the package since malware is already being executed at that point.
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
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.
> 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.
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.
> Devs could setup an option to pacman -U which allows it to bypass VT
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.
Is this accurate? My understanding is that the AUR does not host binary packages. It hosts pkgbuild files, which contain config and scripts that a user has to build on their own machine in order to install. The malicious code here is fetched as part of those scripts.
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.
And even with 3rd party package managers like yay, the package manager is pulling the pkgbuild definition locally, running makepkg for you, and then installing that.
And yay warns you before anything happens and prompts you to review the PKGBUILD files and any patches for this very reason. So there are at least two "are you sure?" confirmations needed before even building anything.
This is a situation where you have to go out of your way and be naive to be affected. You simply can't protect the user from everything.
> Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package.
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.
> 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.
Just create a pacman hook before install that uploads the package there and aborts installation if necessary. Probably skipping repo packages is a good idea otherwise you're gonna spam the API each update.
> We strongly encourage users that may have installed one of these packages […] to take the necessary measures in order to ensure they were not compromised.
How are they supposed to do that when you give them no information as to what the malware does?
Did you install one of those packages? If yes, nuke from orbit.
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?
Per the Wayback Machine the username used was danikpapas. As far as Google and duckduckgo know these are the only packages theat username ever uploaded. Considering the purpose was crime it's likely that that username was "stolen" and the person using it on other sites wasn't the same as the one doing this...
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.
>Per the Wayback Machine the username used was danikpapas. As far as Google and duckduckgo know these are the only packages theat username ever uploaded.
I mean... ... if this was a malicious actor who is to say they don't have 15 aliases on 5 linux distros
They are/were AUR packages it seems, anyone can spend 2 minutes and upload essentially anything there, like npm and similar. It's not necessarily a "maintainer" per se, as like the people who manage the packages in the proper Arch repositories, but entirely separate.
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.
It says what the malware does, it's a remote access toolkit... It gives control of your machine to the malware operator.
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.
Announcements like this typically contain information that will help users identify if they were compromised, such as the name of files that are dropped or modified when the malware is initialized, startup entry names, etc. Obviously the person with remote access can get in and manually start doing things on individual machines, but that doesn't mean there aren't indicators present from the programmatic actions the malware took before that point or on machines that weren't manually accessed.
Expecting a complete malware analysis from maintainers is a tad too much. Their goal is to notify users as soon as possible, even if no other information about the malware is available.
Also, an attacker may leave no traces by simply dumping the payload to /tmp.
In addition to the point about "not being expected to do a full malware analysis"...
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...
This is really scary for those who manage multiple things. I'm considering running a factory reset on everything from my router to my Steam Deck and remote server.
Uh... did you install these AUR packages? It seems quite unlikely you installed these on either a router or a steam deck...
That said, if you did, yeah being hacked is scary and I feel for you.
As @lillylizard pointed out, it turns out that these are new packages, not comprised existing packages like I first thought. Still, the nature of the hack is a Remote Execution, as you pointed out elsewhere, meaning the hacker could pull my router password from the password manager, or grab my SSH keys and log into whatever machine is listed in the known_hosts, or just mess with my Ebay account and the credit card saved on there. The hacker could in theory do literally anything I could do.
Sure, but only if you’d installed the affected AUR packages. Even if they were old packages, probably your SteamOS didn’t install them from the AUR.
Whether or not SteamOS installed them is irrelevant. All the hacker would need is to compromise a machine that had some sort of remote access to other devices (ssh in this case, with some sort of keylogger to decrypt the private key).
You are not compromised unless you specifically installed one of these 3 packages on one of your machines:
- librewolf-fix-bin
- firefox-patch-bin
- zen-browser-patched-bin
The packages were only available for download for 3 days, and the only way you could have installed them is if you explicitly typed one of the package names into your terminal within those 3 days.
Did you do that? If no, then you are not compromised.
I wonder if this is really about compromised packages or rather in wider view trying to paint Arch, AUR as insecure.
I wonder if he even has any unofficial packages installed.
I had the regular librewolf-bin package installed on a couple of my machines. It took me a bit of time to note that librewolf-fix-bin is something separate.
Yeah do not worry, you are fine.
https://aur.archlinux.org/packages/librewolf-bin#comment-103...
It's ArchLinux. The user is expected to do their own due diligence.
And these packages are from AUR, they are not officially supported. AUR means Arch User Repository. You cannot even use Arch Linux's official package manager to install AUR packages either, you need an AUR helper ("makepkg" is sufficient though but it has limitations). These AUR helpers are not even official packages either. Not even yay: https://archlinux.org/packages/?sort=&q=yay.
I’m well aware. Arch isn’t my daily driver anymore, but I used it for many years before really committing to containerization.
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.
It's a remote access trojan. There is no acceptable way to be sure of removal short of full reinstalling every OS installed and reinstalling or rebuilding stuff in the Home dir from known good sources.
In case of any infection, the necessary measures are to take the affected machines offline, extract whatever data you need, and then wipe.
Comments below is from the perspective of an arch Linux user, not maintainer or authors of some software.
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.
https://wiki.archlinux.org/title/Firefox
https://librewolf.net/installation/arch/
This shouldn't reasonably be considered secure because it isn't altogether hard to obscure the nature of the attack until someone notices they are compromised.
Anyone have a copy of it that I can poke at in a virtual machine?
You might be able to poke at the PKGBUILD on the wayback machine and see if the original sources work.
The PKGBUILDs are not archived, but the package page does helpfully list its sources, one of which is https://github.com/danikpapas/zenbrowser-patch.git (same for all three packages). I would assume that's where the malware is, but I couldn't find an archive. Does https://www.gharchive.org/ keep this sort of data?
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...
Could there be programmatic ways to help users characterize the safety of the AUR packages they install? Perhaps a program that prints all URLs in the PKGBUILD and offers the option for the user to open them in the browser? Or which automatically shows a diff if a PKGBUILD is updated? Highlighting changes would make it easier for the user to determine if he should spend time exploring those changes for malware.
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.
PKGBUILDs are just bash scripts following a certain function and variable naming convention. Even if you could somehow parse it safely and extract the URLs of the 'source' array, any attacker can just simply put an obfuscated version of the malware URL into the build() function and download it there.
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.
> 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.
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?
They should all show you the PKGBUILD before building, yes.
LLMs are also really easy to trick, as we saw in the GMail white-on-white text PoC just a few days ago...
This is exactly what many of the AUR helpers like yay and paru already do - ask you to review the pkgbuild diffs before installing or updating.
As one commentor pointed out, in Arch it's the user's responsibility to review any AUR packages BEFORE installing them (and I say this as an Arch user and AUR package maintainer).
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.
I like that idea of printing the URLs it downloads. Will help screen quickly if it's doing something malicious.
As Arch seemingly explodes in popularity I’m afraid we’ll start seeing more of this.
FWIW this is AUR. These packages are not officially supported. AUR = Arch User Repository.
Plenty of package managers (such as `yay`) install from AUR by default.
yay is a package manager that has been made for AUR. yay is not the official package manager for Arch Linux, pacman is, and it does not support AUR. yay is not installed on Arch Linux by default, its official package manager, pacman, is. AUR is for unofficial 3rd party packages, i.e. "use at your own risk". It has always been the case.
Yes, it is "use at your own risk" but most arch users just install from it without giving it a second thought, because availability of packages in the AUR is the one thing Arch is good at.
> most arch users just install from it without giving it a second thought
I'm not sure that's true. Neither I nor most people I know who use Arch (granted, most of them are professional software developers) install software from the internet willy-nilly and without reviewing anything, if by AUR or "curl | bash", especially when on their main computers.
N=1 but I rarely install from AUR and I have been using Arch Linux for decades. Using "yay" is akin to doing "curl | sh". You should inspect the PKGBUILD at the very least, and I do not believe "most users" is correct.
Oh, and by the way, not sure how people miss these:
> Warning: AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
This is from https://wiki.archlinux.org/title/Arch_User_Repository.
> Warning: AUR helpers are not supported by Arch Linux. You should become familiar with the manual build process in order to be prepared to troubleshoot problems.
This is from https://wiki.archlinux.org/title/AUR_helpers.
"yay" is one of the most common AUR helpers, it requires two confirmations from what I counted. One of them is to inspect the PKGBUILD file, the other one is just to proceed.
Those users are going to learn some hard lessons, either in this incident or a future one.
Archlinux is a distro that’s designed for the user to control their own system, and the AUR is clear about what it is and the nature of the packages in it.
It's also good at being fairly simple and transparent, and having the only sane package format in existence (along with Alpine's apkbuild which is basically the same thing), but okay.
> most arch users just install from it without giving it a second thought
Citation needed.
On one hand, the distro developers can’t really prevent people from, say, hitting their computers with a sledgehammer or something. So to some extent, the users have to be trusted.
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.
Yay is a 3rd party package manager. The 1st party package manager does not interact with the AUR.
Yay itself is in the AUR. You have to go out of your way to install it.
The Archlinux docs on AUR helpers lead with a red warning: https://wiki.archlinux.org/title/AUR_helpers
Oh, I thought it was a package from the repo. (I didn’t use any of those third party package managers, just stuck to manually doing everything when using the AUR, which was fine because I used it sparingly).
No, and these AUR helpers are not even official packages in the official repository.
> 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.
I don't remember how yay works but paru (another AUR package manager) displays the pkgbuild file before it will install.
Nearly all distros have this problem when it comes to packaging and distributing 3rd party software.
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.
Is arch exploding in popularity? Because of Omarchy or something else?
The current iteration of SteamOS (the one shipped on Steam Deck) is Arch based. So a lot of non-linux users got exposed to it as their first linux distro. Especially with all the emulation guides and other random guides for doing "advanced" stuff to your Steam Deck by dropping in the Arch-ish desktop.
Also anyone who wants to try "Gaming on Linux" needs bleeding edge kernel which is Arch's default setup compared to other distros.
CachyOS (Arch based distro), no.1 on https://distrowatch.com/
That’s just a ranking of subpage hits per day. Not only is that easily gamed, it also says very little about how popular an OS really is.
This is a slight aside, but CachyOS is a great example of the failure of Wikipedia politics.
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...
It links to https://en.wikipedia.org/wiki/Arch_Linux#Derivatives which indeed lacks any mention of CachyOS. Luckily, Wikipedia is free to register, and you can just edit pages you feel like could be better. Seems like you found the perfect first edit to make for yourself :)
It's an endemic issue on wikipedia, and even editing wouldn't fix this one instance, since someone can (and demonstrably already has) remove whatever you add later on. The issue is wikipedias preference for "deletionism", removing perfectly correct information for no particularly good reason. It's especially pernicious when it comes to short articles, which tend to get deleted with impunity, and redirected to sections of articles, which later get renamed, destroying the link, or removed altogether. Nothing can be done by any individual to fix this issue, since it comes from a wikipedia wide policy, which unfortunately is not one of the things that "anyone can edit".
I agree with most of what you wrote, but unless you can demonstrate that someone actually added CachyOS to the "Arch Linux-based" on the "List of Linux distributions" page and it was later removed, I'm not sure how much it matters how Wikipedia generally works.
I have a long Wikipedia history, but that is not the point. There already was a CachyOS page, and it was removed. Why bother contributing stuff that will just be deleted again?
It might have been removed due to the editor's impression that CachyOS is not significantly different from Arch. With proof to the contrary the page may be restored.
There are a lot of derivative(I don't mean it in a negative way) distors out there, not sure if they all need pages.
Most moderated spaces remove content that doesn't fit the community, Wikipedia does take that to the extreme but I still prefer that than the opposite extreme.
> Blazingly Fast & Customizable Linux distribution
I love Arch Linux, but please...
(Arch Linux is already "fast" (depends on what you install for your DE, if any) and customizable.)
But their differentiation is that to improve performance they compile all the packages with newer instruction sets as the target as well as enabling more optimizations like LTO. And some are even optimized with PGO.
I find it odd to call a specific Linux distribution blazingly fast.
Gentoo with make.conf (/etc/portage/make.conf[1]) having "CFLAGS="-O3 -march=native -flto"" means that Gentoo, a Linux distribution, is performant?
[1] It is not a good idea to build everything with LTO or PGO enabled because not all packages support LTO / PGO cleanly. Do it on the basis of per-package.
I've seen claims of decent speed improvements when using CachyOS, though I can't say I've ever hunted down solid confirmation. I'm a bit wary of the project because I would have to put a lot of trust in them since they're rebuilding everything themselves and could easily introduce malware somewhere in there. (But I've been scared of distros before only to have it pointed out to me that some very well respected people are involved, so I could be worrying for nothing here too)
Does Gentoo have binpkgs with these compileflags? With CachyOS you don't have to compile, because it's a rolling binary distro. Regarding your [1]: They do that, systemd(or parts of it) are unoptimized, for instance. They don't apply that stuff blindly, only where it works.
For me it feels blazingly fast, even on obsolete KabyLake Core-I5/7(t) forcibly clocked down to about 800Mhz most of the times :)
It fucking flies without much effort. On modern systems even more so. While being rock solid. Without any crashes. Even under Plasma. When I'm reading about bugfixes regarding crashes under Plasma I just shrug and think "Waddya talkin about?". That may be hardware dependent, though, because they are old Lenovo Thinkcentres(1Litre SFF M910q tiny) with excellent firmware.
Using btrfs, profile-sync-demon, zram(Yes. Even with 32GB Ram!). Suspend/Resume working every single time. No glitches, hick-ups, ever. So far. Since 10th of June, 2024.
Edit: Almost always some music out of yt doodling in some bg-tab, in oh-so-slow FF, without any clicks, stuttering, or other breaks.
No need for yt-dlp, mpv at all. Except for dl/saving stuff, sometimes. While FF is rarely under 100 tabs.
Actually, there are binpkgs, now: https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart.
My i3 with vim / emacs and even VSCodium flies too, on X Linux. :P
The browser is always the slowest in my case and this has always been my experience, and unfortunately it still is.
Good for you. The 'oh-so-slow' regarding FF was meant as satirical btw. With what I'm using it for, it doesn't lag. Maybe because of https://github.com/graysky2/profile-sync-daemon mostly, and some other fine-tunings, which make it not touching the filesystem over and over again. I really recommend PSD. Not even insane amounts of RAM, it usually takes about 4 to 5GB, rarely going to 8, then shrinking back a while after closing too much tabs. Imagine that!1!! It's all about some sysctl settings :-)
Sideberry (Tree-Style-Tabs like extension) was the ugliest offender there. Though that may have been me misconfiguring it. OTOH I didn't manage to find settings where it didn't do that, and still looked like I wanted it to. At that time, maybe a year ago, I've thought of it as potential 'instant ssd-killer'. Couldn't be bothered. Deinstalled. Now FF has some basic version of vertical tabs by Mozilla itself. It suffices(for now).
Thanks, PSD looks interesting. I only have 8 GB RAM at the moment, I will see if my motherboard supports more (it should support 16 GB at the very least). After the RAM upgrade, I will probably use PSD. Or is there a way to specify how many RAM it can use?
As for tabs, I like the way Vivaldi does it and allows me to customize.
Hrrm. My comment was supoptimal, I guess.
By "Not even insane amounts of RAM, it usually takes about 4 to 5GB, rarely going to 8, then shrinking back a while after closing too much tabs." I meant to say that this applies to the resident size in RAM of the whole browser, not what PSD does, or adds. That would be just what your browser profile is using 'on disk'. Peanuts, so to speak.
With only 8GB it's really hard to tell. It depends on your usage patterns.
First, regarding just PSD, it relies on RuntimeDirectorySize= of https://man.archlinux.org/man/logind.conf.5 which by default is limited to use up to 10% of system memory, but not statically reserved, only "on demand".
Which in turn relies on tmpfs which can use up to half of system RAM by default. Again, on demand only, not statically reserved.
https://wiki.archlinux.org/title/Tmpfs https://wiki.gentoo.org/wiki/Tmpfs
However, I think these are the wrong knobs to turn :-)
PSD can make use of overlayfs, which saves a little bit of used RAM, and is faster to initially sync, but uses more disk space then. But not that much. Which can be further minimized by the number of kept profile backups, or not using backups at all.
Just keep your profile lean and mean, then there's less stuff to shuffle around. Since your'e using Vivaldi, pointing you to wikipages how to make Firefox use less RAM seems pointless ;)
Maybe (carefully) use something like https://www.bleachbit.org for cleaning up Vivalidis profile.
Which leaves things like
https://en.wikipedia.org/wiki/Zram https://wiki.archlinux.org/title/Zram https://wiki.gentoo.org/wiki/Zram https://www.kernel.org/doc/html/latest/admin-guide/blockdev/...
OR
https://en.wikipedia.org/wiki/Zswap https://wiki.archlinux.org/title/Zswap https://wiki.gentoo.org/wiki/Zswap https://docs.kernel.org/admin-guide/mm/zswap.html
to consider.
While it may seem insane to reserve already limited RAM for just another thing, these are worth it. If configured right. I used them, or their predecessors since olden times, when I've just had a Thinkpad T60p with some Centrino and only 4GB.
That made things better in general. Of course it's no silver bullet for everything, but it made the system less sluggish, and it took longer to slow down because of being 'swapped to death'.
From then on I continued to use stuff like that.
On a system with only 8GB, too. ZRAM in this case, because backing device like zswap was impossible, because the HDD blew. So I booted live from USB(2(Arrgh!)) and ran from RAM.
By means of AntiX, which btw. showed my the ways sysctls regarding swappiness, pressure stall information, and related stuff can totally change the behaviour of a system.
Even if it looks strange/ghettoish at first, which can be remastered away easily anyways, the devs really know how to get the most out of older systems with limited RAM and power, in interesting ways. Should be looked at, even if only for 'inspiration', technically.
For instance making things like Firefox shrink back, after having closed too much tabs. And remaining usable, while doing so.
Anyway. Depending on what you do, 8GB only can go a looong way, if configured/used right.
IMO not using ZRAM/ZSWAP, sysctls for swappiness, PSI, etc. is wrong and wasteful.
PSD is just a little icing on the cake.
I am using zram. What would the ideal sysctls be for it for 8 GB (maybe even 16 GB?) RAM?
I think I saw posts on Reddit with XQC saying Arch is the best. I mean it is. And I use Arch btw.
An evaluation of what's best really depends on how one weighs different tradeoffs. For example, Debian and Arch are basically polar opposites in terms of two questions:
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.
There's also the significant caveat with 2 that it's only "continues to work the same way" until everything changes all at once because you now need to update to the next version of Debian.
The "everything changing all at once" thing is what eventually drove me to arch (as the most popular at the time rolling release distro - and more stable at the time than debian sid), I'd personally rather have smaller breaking changes more frequently. Though it's probably less painful now to update debian versions than it use to be because things generally work better without configuration than they used to.
The only thing I've seen Arch exploding in popularity has been memes. It's a fun distro for hobbyists, but too inconvenient as a daily driver.
This is just ignorant. I've been daily driving Linux since 2005. The majority of that time has been with Arch. Despite the memes, I've found it to be MORE stable than your typical Debian derivatives. It's funny to me that it took over a decade for people to come to the same realization.
You know? I did drive Arch daily for a few years, coming from NetBSD.
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!
Can you elaborate why you think this?
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.
I'm hesitant to comment further seeing I've attracted the ire of some people with my comment, but anyway. I too used Arch out of curiosity about like ten years ago, during the first "Arch, BTW" memes, and found it too unstable, but that's expected from a rolling release: update too soon or too late, and something could break. I didn't mind, as it was a hobby.
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.
FWIW, the only breakage I've seen over the past 5 years is amdgpu bugging out on latest kernel releases, which is easily solved by running linux-lts.
I've had way more problems with Ubuntu trying to be convenient and bringing in lots of Windows-style automation that breaks more often than it works (and when that happens, you're really on your own since you have no idea how it's put together — just like in Windows).
Or even just bugs that were solved upstream ages ago (and have been available in every rolling-release distribution, including Debian testing/sid).
The current Arch installer suggests btrfs with snapper, so you get automatic snapshots pretty much out of the box (need to check one flag in installer), and can easily rollback if something breaks. Not something I needed, but it's there.
I can't imagine what kind of a problem I would personally have to encounter to make me utter such a sweeping generalization with this much confidence. :)
At least this guy has been using it as a daily driver (at home and at work) for at least fifteen years.
I've been using Arch as my daily driver for over fifteen years. I'm not a fanatic, it just works really well.
If Arch is too "inconvenient" as a daily driver, you might find yourself more at "home" on a Windows install instead.
Well, Arch has (historically) been rather difficult to install from scratch, and requires a lot of Linux knowledge to get up-and-running as a daily driver. If one is installing it for the first time and misses something (which audio backend?), it can be rather frustrating down the line.
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.
It this recent? I thought “I use arch btw” was more of a thing… 5 or so years ago.
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.
Any clue what these packages were 'supposed' to do or why somebody might have installed them? Their PKGBUILD descriptions are copies of the respective browsers', not explaining the -patched part.
Looks like someone archived the page of firefox-patch-bin[1] and the only thing that stands out about the package itself is that it's supposedly the "Extended Support Release." Besides that it looks like it's depended on by 183 other packages/metapackages. While that seems more interesting, there isn't an archive of all of those packages.
[1]https://web.archive.org/web/20250718140411/https://aur.archl...
These 183 packages depend on "firefox", and the malicious firefox-patch-bin had a provides=( 'firefox' ) clause in it. That's why they all get listed on that page. The provides clause is useful when you have multiple packages for the same thing with different names, for example -bin and -git versions.
I saw the ESR part - I assumed the author (mistakenly?) copied firefox-esr's description. As for the dependents, it seems the malware package provided `firefox`, meaning all dependencies on `firefox` can instead be fulfilled by `firefox-patch-bin`. Perhaps the idea was to fool package managers into showing it as one of the alternatives.
I wondered about the same thing. Not an answer, but my guess would be that it's just a new package and they hoped someone picked it up by accident? In that case, it was patched with malware :)
They (or someone in cahoots with them) made at least one attempt [0] to lure readers of the Arch Linux subreddit to the malicious PKGBUILD.
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...
I wonder how popular these packages were. Librewolf and Firefox sure are popular, so this sounds scary, but for example searching for "firefox-patch-bin aur" yields no results, aside from sites talking about how it contained malware.
My impression is that the malice was spotted timely, and not many people were affected. Which is a pretty good thing!
Man. I am on Fedora, but I do have a handful of copr packages installed. (Copr is the Fedora analogue of the AUR.)
This makes me nervous. I guess it’s time to do some audits.
It seems odd that this is just on the AUR mailing list, and it the homepage, the announce list, or the security list.
Why would it be? AUR is user generated content by definition, you're expected to read and understand every package before using it, which is repeated in documentation ad nauseam. They're very, very explicit about this and that you're on your own when using AUR.
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.
This feels like a non-sequitur.
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.
I guess we have very different takes on this; I wouldn't expect Slack or WhatsApp to publish security advisories if one of their users used them to spread malware among a tiny cohort of other users, which is about the right level of responsibility Arch places on itself (and it's very clear about this) w.r.t AUR.
I think you’re correct. I see a fundamental difference between services like slack and WhatsApp which provide messaging services and hosted platforms like the AUR where content is submitted and then republished on a site administered by the project.
it should be noted that these are different from the popular librewolf-bin (513 votes) and zen-browser-bin (176). with this in mind it's cool that these got identified only 2 days after being uploaded. I wonder if the reporter actually intended to install it or just reads the PKGBUILDS of new packages to be a good samaritan...
I only just noticed the difference myself. That was a scare!
There's always been this security theater of people recommending arch because they "don't trust the companies" or Canonical or what have you but frankly I'm surprised this hasn't happened sooner. Well or maybe it has and we don't know.
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.
Arch bugfix time is usually within 24 hours.
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.
I agree, it's much better in Ubuntu land where you simply won't have the software at all, will shrug your shoulders and go on with your life.
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).
How exactly is Arch barebones? It basically ships with everything I need, more than most distros (Zed and Discord are good examples). I don't even need to use the AUR.
Just by taking a glance at the most popular packages (https://aur.archlinux.org/packages)
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.
Chrome is in the main repos as chromium. VS Code is the "code" package. I don't know what vpn clients you're referring to, but networkmanager is built-in and has support for openvpn and wireguard.
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.
And what distro does package those?
That's what Flatpak is for. If you must install crappy proprietary software, at least get an official package from the developer.
> And what distro does package those?
nix, which has its own share of problems.
> nix, which has its own share of problems.
Care to elaborate?
Some of those packages (like Brave) are maintained by original developers, it depends on the package.
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.
i installed a lot of cra* from aur in the past, wouldn't be surprised if i got a malware somewhere. Strange thing, I don't think open snitch would even help in such situation..
and official repo does not have enough packages to run arch :\ I don't want to go back to ubuntu
I haven't taken a look at the malware, but it seems to download files from the Internet so it should have warned you to allow/deny the outbound connections.
It'd be nice to test it with a sample of aur package/malware.
it does, I am using it extensively (little snitch on mac, and open snitch on linux). My problem with it is that every new tool wants to connect to the internet and my terminal is the constant source of outbound connections. I try to review everything but the amount of tools and connections is overwhelming. It does limit the risk, but i do not trust my terminal and dev tools as usually i give them way too many permissions and any plugin or tool from AUR can contain 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
AUR packages are user-produced content i.e. packages built on their own machines.
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.
First of all, this is incorrect, the checking would have to happen _before_ even building the package since malware is already being executed at that point.
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.
> malware is already being executed at that point
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.
It seems like you may not be familiar with Arch?
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.
> 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.
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.
> Devs could setup an option to pacman -U which allows it to bypass VT
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.
Is this accurate? My understanding is that the AUR does not host binary packages. It hosts pkgbuild files, which contain config and scripts that a user has to build on their own machine in order to install. The malicious code here is fetched as part of those scripts.
No, it is NOT accurate.
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.
And even with 3rd party package managers like yay, the package manager is pulling the pkgbuild definition locally, running makepkg for you, and then installing that.
And yay warns you before anything happens and prompts you to review the PKGBUILD files and any patches for this very reason. So there are at least two "are you sure?" confirmations needed before even building anything.
This is a situation where you have to go out of your way and be naive to be affected. You simply can't protect the user from everything.
Yeah, it is called an "AUR helper" officially because it just automates these processes for you.
> Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package.
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.
> 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.
> 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.
Between false positives, high QPS, and the fact malware devs would then test against Virus Total, is this useful?
Just create a pacman hook before install that uploads the package there and aborts installation if necessary. Probably skipping repo packages is a good idea otherwise you're gonna spam the API each update.