The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of.
I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach.
But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.
The bad news, of course, is that the Linux desktop is a bit of a train wreck in terms of security hygeine. It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, and I fully expect we'll also see more malware propagated through KDE's New Stuff integration (which goes through Pling.)
I think KDE's approach is a greater danger. They both come with warnings, but with AUR (depending on tools) allows you to inspect the PKGBUILD. KDE just gives you a warning and no easy way of looking at what you are installing, it is not clear what contains executable code, and its enabled by default.
In general things that are not part of your distro's supported repos (KDE's AUR, language package installers like npm and pypi, Ubuntu PPAs, etc.) seem to present far more of a risk.
I'm not sure if it is that the desktop is being taken more seriously, or that its easier to write code that works on many distributions and configurations, greatly reducing the cost and increasing the value of the existing 'market'.
I would say that it is now very easy to steal 'AI' providers credentials this way. And then you can use them to write more malware or scam or use models for generating speech to call people and get them to 'redeem'. Or at leat to me this seems more sensible than injecting just malware.
> But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.
Absolutely the wrong conclusion:
1. This is a super low hanging fruit attack
2. The ROI is significantly higher than the cost of attack
3. The cost of the attack is now drastically reduced due to LLMs (not that they necessarily mattered here but hard to rule out).
It’s less about the Linux desktop where Ubuntu is dominant and more that Arch security is so bad regarding how they maintain the AUR. Seriously it’s worse than Swiss cheese in terms of putting up roadblocks.
> that Arch security is so bad regarding how they maintain the AUR
I still don't understand what people expect Arch to do here? It's a user-contributed repository open for anyone, Arch maintains their own official repositories that are separate from AUR, what would need to change in the maintenance of the AUR for you to consider it to be "properly run" or whatever, and it doesn't stop serving its core purpose anymore: to allow any user to upload any PKGBUILD?
If you're advocating for not allowing users to upload their own PKGBUILD anymore, then it stops being the AUR, and for the people who agree with that, they can already exclusively use the official repositories instead of touching the AUR.
In true Arch fashion, the security is up to you here, review stuff before installing 100% unknown and random 3rd party software from the internet, as always. If you don't want to review anything? Stick with official stuff, and you won't have issues.
> The AUR is maintained by Arch's Package Maintainers
So, firstly it is their responsibility. The consequences are a direct result of their policies.
Example of changes:
* orphaned packages don’t need to be adoptable.
* doesn’t have to be a flat global namespace
* they could have offered the cooldown capability a long time. This isn’t an area they focus on until they’re absolutely forced into it through sheer embarrassment of the scale of the attack.
* they could be running scanning tools on every change to try to catch low effort attacks like this
But sure, if you throw up your hands and say “we’ve tried nothing and nothing works” then you shirk all responsibility. And maybe shutting down the AUR is the right move if the current incarnation is so bad and the people running it don’t know how to secure it.
Think of it this way - the NPM and cargo registries handle way more traffic and visibility and doesn’t have any issues like this. There they have to deal with more complicated supply chain attacks. Ubuntu and Fedora take a completely different tack with user-contributed packages that are namespaced and better sealed.
And part of this of course is that yay and ilk don’t do proper sandboxing. But that’s just more shirking of responsibility by the AUR maintainers to force the community to try to do this and failing to treat this as an end to end problem they need to own
> orphaned packages don’t need to be adoptable - doesn’t have to be a flat global namespace
Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.
It's easy to complain about other volunteers to non-profit projects are not doing enough, but truth is that there is always a lot of stuff to do as an volunteer, and while you try to fight fire X, people scream about fire Y, and vice-versa, depending on which one made the news most recently. Sure they should be scanning things, sure the official repository should be super fast and always available, sure every package should always be problem free, but it's a human project driven by humans essentially for the love of the project itself, in one way or another.
Cargo in general have the benefit of being new (shoulders on giants and so on), and being made by people who knew what they were doing. NPM has had a long struggle with a lot of stuff though, and is today maintained by one of the largest companies in the world. I'm not sure they're really comparable here.
I do agree the process for which orphaned packages get new maintainers needs to change, obviously shouldn't be possible launch such automated attack. I don't agree with that the feature as a whole should go away, I do have my own packages that depend on other AUR packages, surely many of them have through the years changed maintainer, but shouldn't mean I need to suddenly start using a different package, as long as I continue reviewing the updates.
> Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.
This is the problem - the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up. You’re essentially there in some ways without admitting it because of new account creation is disabled. The next attack vector will be taking over existing accounts that aren’t used.
Think of it this way - Arch is a niche distro within a niche desktop OS and still it was cheap enough of an attack that it was worth it. It’s a cultural problem and your mindset is precisely why this will keep happening. As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
> the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up.
It has outgrown the mindset that AUR is for people who use and follow the advice of Arch Linux? Or what do you mean? What I'm describing is a workflow you can apply today, apply it equally to all packages, and it stops 99% of the hacking attempts and the remaining 1% wouldn't matter if it's via AUR, NPM or Cargo, same issues remain.
> It’s a cultural problem and your mindset is precisely why this will keep happening
I agree that "Anyone can automatically take over 100s/1000s of packages as a maintainer" is a problem, I don't agree that it's a deeper problem than that. Limit each user to be able to take over one package per month, and suddenly we get all the same benefits we have already, + we fix the current issue.
No need to trash the entire AUR when there is one specific feature broken, just fix that feature, then continue your pragmatic life as before.
> As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
To be fair, if I ended up misunderstand something so deeply that I didn't realize how to actually use it, I'd be embarrassed myself as well, strong of you to at least state so publicly. I'm happy you at least figured out that Arch Linux isn't for you, and you start trying to find a distribution that fits you better, rather than going through a tough period of time trying to change something into a direction it isn't even aiming for.
Installing anything from the AUR, it has always been the user's responsibility to check whatever they are installing. Has always been this way, and they have always been abundantly clear about this. It is also the reason why archlinux does not provide an official installer like yaourt or yay, they could've even built support for the AUR into pacman.
The AUR is just as safe as installing through a random shell script from github - that is to say: not safe at all.
The issue with the AUR is that its design and the way package maintainership works puts users at undue risk compared to many other "user" repositories. This happens because so many useful packages are only available in the AUR to begin with, but also because the mechanism for taking over an orphaned package is just simply too open for exploitation.
I don't have all the answers. I hope people will consider Nixpkgs as a powerful model: even though it has many thousands of PRs unmerged at any given time and requires substantial effort, it still operates at an absurd scale and yet has a higher bar to infiltration with malware, both due to build sandboxing and due to the review process. Whereas AUR maintainership is mostly handled individually per-package, anyone can submit changes to a Nixpkgs and try to get it reviewed, even if the maintainer of an individual package is long gone (though we usually give maintainers a week or so to take a look at a PR even once it has been reviewed.) This entirely gets rid of both the need and incentive to have a process to replace an orphaned package's maintainer: writing yourself in as the maintainer mostly just signs you up to get pinged for issues and PRs, it doesn't grant you special permissions to bypass the normal review process.
A giant monorepo of PKGBUILDs with a similar maintainership model plus makepkg sandboxing would be fantastic. makepkg sandboxing would be nice just for ensuring that packages correctly declare their dependencies.
I think the sandboxing thing has a better shot at actually happening, since redesigning the entire AUR around a completely different model is probably an unreasonable leap. That'd still be a pretty good improvement, though.
It seems obvious to me that they should get rid of this "orphaned" designation that allows anyone to grab a package and start pushing updates, because there's no circumstance under which that's a good idea.
> It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world,
When opening the printer configuration page in the KDE configuration panel, I was pleasantly surprised to see it's process runs wrapped inside a bwrap session. Cups is a bit of old and dangerous; I'm glad they sealed that off inside a sandbox. If you ask me, I would make this approach the standard for any software. The configuration panel for fonts doesn't need network access, so at least `bwrap --unshare-net`
Snap has had a couple of attacks, at least. I recall one that was a fake crypto wallet. I'm sure Flathub has, too.
That said: the attacks on Snap and Flatpak are bound to be less interesting; it doesn't share the same mechanics that make AUR scary. I still hope that Linux infrastructure vendors work to come up with good ways to "raise the floor" in these cases.
In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks. You can control the threshold since it's just user configuration now.
This is a good thing, because the warning about checking everything you download from the AUR, which has always existed, is now actually "enforced". People respond to consequences.
A lot of people in this thread seem to be treating this situation as a referendum on the security of package repositories that allow anyone to create a package. Possibly because that's interesting to more people, since npm and PyPI are more widely used than Arch.
But unless I've badly misunderstood something, the key thing that made this attack possible is this "orphaned" thing that lets you grant write access to an existing package to the first person who claims it, without any control over who that is. I don't see how this could ever be a safe thing to do, I'm not aware of any other package repository that has it, and I struggle to guess what whoever built it was thinking. If AUR just turned off that misfeature, they wouldn't be having this problem.
(The article quotes someone involved as saying that the "orphaned" feature is good because good actors can also use it, but that seems irrelevant if it also opens up an unmitigable machine-takeover vulnerability. World-writable single-namespace systems like Wikipedia work by having humans proactively checking for bad changes, and also by it not being that bad if a page is briefly defaced, since you can't push malware to users' machines that way.)
Humble question: how do you find out if your system has been affected by a malware?
I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any?
I haven't run an antivirus since I last used Windows 20 years ago.
In theory, you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens, but of course not earlier. And if your root/hardware somehow is infected, your monitoring/management tools might be affected too, so then you're basically out of luck except with external network gear outside of your computer. But then those could be infected too, and so on.
Ultimately I'd say it depends on your risk profile, but using something to actively approve/deny network connections on your local machine, is a great start that'd defeat most of these simpler "exfiltrate information ASAP" malware that seems popular at the moment.
> you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens
If you have a list of good CLI utilities, you could run them in a bash script (e.g., network-monitor.sh), which would run in the background, and then redirect the output data to another file (e.g., network-monitor.txt). The key concept here is "baseline" -- you need to know what normal baseline network activity looks like, so that you can identify anomalous behavior. The way to establish a baseline is to gather a lot of data from the system.
The following are a few useful command line utilities to use for a host intrusion detection system (HIDS) using a simple network monitoring bash script. However, I am not sure exactly how to tweak the options. Also need to find a way to check for data exfiltration:
-list open ports and processes that own them: netstat -lnp
Then it would be relatively easy to write a python script with regex tools to parse the network-monitor.txt file, establish a baseline, analyze the data for patterns and search for anomalous behavior.
Besides network monitoring, there are other command line utilities you can use to check the system for possible intrusion, which you could run in a separate bash script as part of your Host Intrusion Detection System (e.g., hids-users.sh):
-show members of root group: cat /etc/group | grep root
-show users logged in: w #if you are the only user, you should not see more than one account logged in
-search for all accounts with UID of 0: grep :0: /etc/passwd #ideally there should be only one UID of 0 on the system, but attacker can create more.
-check that daemons who never log in have * or !, meaning no passwd: cat /etc/shadow
-look for orphaned files, possible sign of attacker temp account deleted: find / -nouser -print
-search for new user accounts that are not part of regular build: sort -nk3 -t: /etc/passwd #sort numerically third column (UID), colon delim (-t:)
EDITS: several small changes for clarity and also in response to comment below
> tail your network-monitor.txt file to watch for anomalies in the network connections and check for any strange outflows of data
Don't do that, you can't rely on "watch for anomalies" with your human eyes.
Either you setup something that notifies you after the fact, or you outright block all incoming/outgoing connections until you approve them. Mentioned elsewhere I think in the thread, I think both OpenSnitch, Little Snitch and PiHole can help you with all of these things.
But don't assume you can "watch for anomalies", automation and/or gated access is probably the way to go.
> you can't rely on "watch for anomalies" with your human eyes
Yes, I agree, that's a good call. I would not try to check for anomalies manually with meatware. I would parse the data with python regex tools to establish a baseline and search for anomalous patterns.
I edited my post to reflect the change you suggested.
> Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any?
>
> I haven't run an antivirus since I last used Windows 20 years ago.
That'd be the role of an IDS (Intrusion Detection System). Things like file signatures of your entire system being saved to another machine (for example an offline/airgapped one) beforehand (for example by plugging your main machine's SSD as a secondary drive on the airgapped one).
If you suspect shenanigans, you take your machine offline, you remove its SSD (your BIOS/UEFI is also a concern), plug it to your airgapped machine with the IDS: it compares all the files (binaries, config files, etc.)' checksums with the past ones.
It's a bit of a lost art but it could make a comeback seen what we're facing, now nearly on a weekly basis.
Some distros have a way to check for file integrity as part of the package manager: but you can't trust the infos coming from the machine itself if it's been compromised.
The AUR is effectively a pastebin for PKGBUILD files.
Some people (many of which don't even use Arch itself) have been treating and advertising it as something different. It's not a software distribution method meant for normal computer users.
Note that the AUR attacks were part of the larger miasma worm campaign, gradually trying to gain more control through various package ecosystems since the RedHat prototype campaign.
What is a good review? Or different tiers of review? When thinking about packages, say in npm world, I still wonder about trust within nested dependencies. New users might also be unfamiliar. Any thoughts or any guidances?
I'll note that OpenSuse also has Packman which a shitton of people enable (for codecs), has also 'one namespace only' an looser policies than the main distro.
I do not think this something you can escape by switching distro.
Zypper at least has a notion of "vendor", so you can arrange things so that only the handful of packages you care about will actually come from Packman.
Ubuntu actually has first-party repositories with proprietary codecs.
Nixpkgs is a pretty comprehensive monorepo of packages with a more normal review process than the AUR, and it includes non-free software as well, plus the model with flakes for third-party stuff is that you trust individual publishers for their little repos rather than one giant grab bag repo of unreviewed content like the AUR.
RPMFusion for Fedora kinda has a similar profile, in that it's a shared repo for various things unsuitable for the main one, but it follows more or less normal Fedora packaging and review standards, doesn't it?
Supply chain attacks are possible everywhere and some distros have particular weaknesses, but the AUR really is pretty much uniquely bad here.
I use Gentoo. You have to specifically install "overlays" and every package maintainer would make their own overlay. You can't easily take over an overlay without the original person's permission.
That being said, still one namespace. Once you add an overlay it can replace any package it wants.
It's also Gentoo so too hard for most people to figure out.
Yes, the only reason this isn't happening in other distros is simply popularity.
Namespacing is the solution, and as mentioned in the article some ditros do indeed have namespaced user repos, like Fedora's Copr. The trust model of a flat namespace user repo is completely broken when the maintaining user can change at any moment.
"One namespace" is also technically true but doesn't work the same way with dnf or zypper as it does with pacman. dnf and zypper both make it easy to be explicit about the priorities of your repos and also to track which packages come from which repos and prevent that from changing. Plus openSUSE has a generously free public instance of the Open Build Service that you can easily use to host your own repos, and which hosts many individual repos you can add for specific purposes. When I ran openSUSE I always just ran my own repo there with only the extra packages I actually wanted, often just "forking" packages from repos hosted by well-known openSUSE developers so that I didn't have to manage updating the source packages myself but still didn't pull in the whole world from those repos and also didn't implicitly trust anything as loose as the AUR.
OBS is more like Ubuntu's Launchpad or Fedora's CO0R than the AUR. Random strangers can't take over the packages of others just because they go idle, and it's a bunch of separate repos, not one. Totally different trust model.
The funny thing is: with FOSS you know what's going on attack-wise as they are transparent , but there must be huge upheaval in the closed source (e.g. MS) software that is just kept quiet by stock-price-chasing executives.
Despite that official Arch repos weren't affected in this attack,
I would not recommend using Arch (or any rolling release distro)
for anything that requires security.
(Imagine if the xz backdoor targeted Arch...)
An Arch maintainer that I personally know once admitted that he
rarely review upstream changes when bumping package versions.
He only does that when the build breaks.
I can't blame him for what he did, since it's not reasonable to
ask package maintainers to spend all their time on those stuff,
especially in this "Age of AI" where more and more software are being
aggressively refactored (or rather rewritten) and added more features.
What we can do is choosing a stable distro (like Debian) where
packages are more thoroughly reviewed, and apply security practices
(such as TOTP, sandboxing browsers and video players, etc.)
even though they cause inconvenience.
It's a complete fantasy that Debian maintainers do a thorough review of changed packages. It's not a responsibility they have, and it would be impossible anyway (how many packages are there in Debian? How many maintainers are there?).
> An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions.
Cool story bro. Assuming that's common, I have trouble understanding why Arch (non-AUR) is any more at risk than Debian--besides the latter being more popular and having more users/incidental testers, which is a real benefit if that's your goal, but has its own drawbacks (like older and known-vulnerable packages lingering for longer before updated releases are made available).
> it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI"
Aren't Debian and friends similarly at risk of this as well, then?
> security practices (such as TOTP, sandboxing browsers and video players, etc.)
I'm not sure if those are more or less prevalent on Arch; I know that many IDEs and GUI programs I've installed on Arch ran by default in Flatpaks or similar, and Debian/Ubuntu like Snaps, but I'm honestly not familiar with whether those ecosystems have significant and/or equivalent penetration in different distros.
Debian freezes the package versions on release of each Debian version and then cherry picks critical fixes for the rest of the Debian version's lifecycle. So even if they never review the code (and I don't expect them to), they're less likely to release malware before it's discovered by others.
That model is getting increasingly difficult and labor intensive, unfortunately. More and more upstream are abandoning the old school security advisories. Not many are isolating CVEs or security fixes into distinct patches, the fixes come with a version bump and often accompany new features or other bug fixes.
There's also plenty projects that silently fix security bugs without issuing a CVE or even labelling them. So now the maintainer of that packages has to monitor the commit logs, figure out if a particular bug fix has security implications and then backport it to the older version which is becoming harder and harder over time.
Unless you have a massive team or a big enough army of volunteers, the LTS model is becoming less and less viable over time, you are often safer on rolling release or close to it (something like Fedora's pace is good).
You get a lower risk of them pulling in a bleeding edge vulnerability, but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue (or introduce more issues based on how they diverge from upstream).
> but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue
Which is why the whole process is open sourced and you can get easily the source version of a package, edit it and rebuild it.
Alarming. The whole point of official repositories is they're trusted, since they are maintained by trusted people. If one can't trust maintainers to be responsible, then the official repositories are no different than the AUR.
there have been multiple package list checkers released, but unclear which ones are trustworthy, I can't immediately find a list from the official channels (through AUR website) to such approved scanners?
Well all of those attacks are just supply chain attacks, and it is basically exploiting people's trust. With LLMs, the speed and velocity of pumping out malice raised are now significantly faster.
It is so sad that every goodwill eventually got enshittified as well.
The AUR has consistently had warnings around it of 'verify the PKGBUILD', far more so than any other package repository that allows anyone to sign up. Probably the only notable difference is the ease of taking over an orphaned package.
The AUR is not the Arch package manager or repository. The main Arch package repos are managed similarly to Debian, or Fedora, or whatever--caveat Arch's nature as a rolling release, but in terms of vetting and ownership/security, the approaches are similar. pacman installs from regular, real, vetted repositories by default. pacman will never install from the AUR. pacman is the official Arch package manager and the only one that is provided with the main Arch distribution/install instructions.
The AUR is, as many others have pointed out, a deliberately un-vetted pile of random Git repos. Arch deliberately doesn't even ship with a default one-click installer for AUR packages; their published guidance is "git clone this stuff from wherever it's hosted and build it at your own risk". Plenty of third-party, non-Arch-blessed tools turn that into a one-click process, but it's not "part" of Arch itself--at least not any more than, like, curl | bash or directions on how to add rando websites to /etc/apt/sources.list.d is part of Debian and friends.
I've used Arch as a daily driver for years. At peak, I've had five (5) total packages, with no transitives, installed from the AUR. Today I have one: sublime-text-4. It's perfectly possible--and extremely reasonable for many users, even power users--to live in an AUR-less world, or to use so few AUR packages that the guidance of "read what you're installing, doofus" is manageable and not onerous.
AUR is fast and loose and doesn't do much "handling" by design, so it's hard to find any equivalent repo. But there's always a tradeoff between fresh (nixpkgs unstable, might be the closest) and tested (Debian).
AUR isn't just the testing repo of Arch; it's explicitly just an open spot where anybody can put up "here's a PKGBUILD for folks". I don't see how it's like either the Nix or Debian examples.
Well, Nix has NUR which is a direct equivalent but it's not nearly as broadly used and I assume "here's a PKGBUILD for folks" is already too permissive for you if you're asking.
There's no maintainer vetting process in nixpkgs as far as I know, anyone can own a bunch of packages. There are quality standards and it's not "here's a bunch of nix code for folks" but it's the next possible thing in the line after that.
It seems like you may have mistakenly inferred that I have issues with the AUR?
I don't; I use Arch on 100% of my personal servers, have done so for something approaching 20 years, and don't see myself changing.
But I treat the AUR for what it is: a place where anybody can say "here's a PKGBUILD for folks" and it's on me to evaluate it on its merits.
I was legitimately asking the person upthread what other distro they felt had a better model for this kind of sharing, because they seemed to think this was a reason for Arch users to jump ship and I was curious what they thought would be the elements of a better system.
The NUR was sort of convenient before flakes were a thing, but now that there's a really common convention for sharing Nix code few use it. I bet most people who came across Nix in the last 4 years have never even heard of it.
No because there’s no way to handle an open submission repository at all. It’s impossible by design since anyone can submit packages to it.
I would never use anything equivalent to AUR on any distro due to the obvious security implications. That’s been my position for as long as I have known about Arch. I never understood Arch users using the AUR as a selling point for the distro.
Then again I live in the opposite end of the spectrum where I run only Debian Stable on my Linux desktop as well as my servers, where packages make it through Sid and Testing before getting to Stable and I can be relatively sure any supply chain attacks have been caught by then (like xz for example which was caught before it left Sid).
For those unfamiliar with Debian, Sid is basically a rolling release similar to using Arch with the official repositories (which is already dangerous without even touching the AUR), then packages move to Testing, then later eventually make it to Stable.
The AUR is, in my opinion, a pretty convenient selling point if you use any esoteric software.
It’s basically like a crowdsourced set of people’s tips and tricks for installing stuff on Arch, all written in the format Arch uses for packages.
Similar to how I’d not blindly take code from an AI and whack it into production, I wouldn’t blindly take an AUR PKGBUILD and execute it. But it’s nice to have a place to go see “huh, I wonder if anybody has shared their approach so I can borrow from it”.
That’s a perspective on the AUR that I hadn’t really seen before from Arch advocates, in my (admittedly hazy memory) it’s usually mentioned in the sense of “Arch is great because you always get the latest packages in the official repos and basically anything you possibly need you can just install from the AUR”. If you’re actually using it just as a reference guide essentially then it seems like there’s some value there.
However, I’ll push back a bit from my perspective as a Debian Stable user. I would consider even the official Arch repositories to be dangerous just like I consider Debian Sid’s repos to be dangerous (packages are too new and not sufficiently vetted). Then regarding installing packages not available in the main Debian repos, I’ve never really had any issues installing them either as there is always either an official developer run apt repo I can add, or an official deb package, or it just builds directly from official source without tweaks. So I’ve honestly never felt like I was missing “a crowdsourced set of people’s tips and tricks for installing stuff” on Debian as I’ve just never needed one.
I do realize that installing the latest packages directly from a developer’s repo or latest deb package or source is as dangerous as the Debian Sid or Arch official repos for the same reason (too new, not vetted), but the difference is those are only a tiny portion of the packages installed on my system (like a percent of a percent, maybe a half dozen packages out of hundreds). If I ran Sid or Arch, it would be 100% of the packages on my system which is an attack surface orders of magnitude larger.
EDIT: It did just occur to me after posting this reply that I use Homebrew pretty extensively as a package manager on macOS and its official repos are equivalent to Sid/Arch official repos, so I may be a bit of a hypocrite here :P
Opensuse OBS. Tiny bit better because the build environment doesn't allow a network and binaries are not allowed as far as I know. Fedora has a similar thing COPR. Both of these support building packages for other distros as well as appimage, flatpak etc.
With opensuse official packages also use the same infrastructure. It is actually quite fascinating and powerful. (I know a lot less about COPR but I would imagine it would be equally as good. Wezterm switched to that for its packages)
Gentoo's model appears to be basically the same? Like the AUR, anybody can submit basically anything they want. The requirements amount to containing valid packages, having a bugzilla account, and putting your package definitions in VCS somewhere.
Yay isn’t in the official arch repos? The only way you get stuff from the AUR is by explicitly pulling down to repo and building with makepkg or explicitly finding and installing an AUR “helper”.
You think that users having to find and download software from the Internet at large is both similar to the AUR model and has preferable handling of these issues?
To me, installing software from the AUR sounds a lot like downloading Windows software from .info sites and torrents. It's mostly fine, but it's not exactly a surprise when things go wrong.
> New user registration was stopped on June 11 and then re-enabled after the project added Anubis to try to foil the attacker's mass account registrations. That did not work
This confuses me - why would a proof-of-work anti-scraping system like Anubis prevent registrations?
Implementing a bot to do registration is not a "copy as curl " click away anymore, and creating millions of accounts maybe become computationally expensive.
This is not much, but it could deter some low effort adversaries.
A side note, isn't package maintenance something that can actually be solved to some extent by LLMs? The prompt would be something like "Clone this repo and build this package while building/bundling as few other packages as possible with minimal code changes."
Then set it in a loop on all the packages for a particular system, I don't have experience in package maintenance and would be curious what kind of issues would come up.
Packaging for Linux distros is about review, following standards and conventions, authority, and responsibility. (And maybe also sometimes patching for compatibility.) LLMs can sometimes help with some of the mechanical parts, but the curation and trust stuff not so much.
And everyone does this individually you mean, rather than sharing the result as 'a package'?
It's an interesting idea, not sure I'd recommend it broadly, but if someone told me they prefer to trust an LLM than third-parties I'd get it at least.
The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of.
I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach.
But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.
The bad news, of course, is that the Linux desktop is a bit of a train wreck in terms of security hygeine. It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, and I fully expect we'll also see more malware propagated through KDE's New Stuff integration (which goes through Pling.)
I think KDE's approach is a greater danger. They both come with warnings, but with AUR (depending on tools) allows you to inspect the PKGBUILD. KDE just gives you a warning and no easy way of looking at what you are installing, it is not clear what contains executable code, and its enabled by default.
In general things that are not part of your distro's supported repos (KDE's AUR, language package installers like npm and pypi, Ubuntu PPAs, etc.) seem to present far more of a risk.
I'm not sure if it is that the desktop is being taken more seriously, or that its easier to write code that works on many distributions and configurations, greatly reducing the cost and increasing the value of the existing 'market'.
I would say that it is now very easy to steal 'AI' providers credentials this way. And then you can use them to write more malware or scam or use models for generating speech to call people and get them to 'redeem'. Or at leat to me this seems more sensible than injecting just malware.
> But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.
Absolutely the wrong conclusion:
1. This is a super low hanging fruit attack
2. The ROI is significantly higher than the cost of attack
3. The cost of the attack is now drastically reduced due to LLMs (not that they necessarily mattered here but hard to rule out).
It’s less about the Linux desktop where Ubuntu is dominant and more that Arch security is so bad regarding how they maintain the AUR. Seriously it’s worse than Swiss cheese in terms of putting up roadblocks.
> that Arch security is so bad regarding how they maintain the AUR
I still don't understand what people expect Arch to do here? It's a user-contributed repository open for anyone, Arch maintains their own official repositories that are separate from AUR, what would need to change in the maintenance of the AUR for you to consider it to be "properly run" or whatever, and it doesn't stop serving its core purpose anymore: to allow any user to upload any PKGBUILD?
If you're advocating for not allowing users to upload their own PKGBUILD anymore, then it stops being the AUR, and for the people who agree with that, they can already exclusively use the official repositories instead of touching the AUR.
In true Arch fashion, the security is up to you here, review stuff before installing 100% unknown and random 3rd party software from the internet, as always. If you don't want to review anything? Stick with official stuff, and you won't have issues.
> The AUR is maintained by Arch's Package Maintainers
So, firstly it is their responsibility. The consequences are a direct result of their policies.
Example of changes:
* orphaned packages don’t need to be adoptable.
* doesn’t have to be a flat global namespace
* they could have offered the cooldown capability a long time. This isn’t an area they focus on until they’re absolutely forced into it through sheer embarrassment of the scale of the attack.
* they could be running scanning tools on every change to try to catch low effort attacks like this
But sure, if you throw up your hands and say “we’ve tried nothing and nothing works” then you shirk all responsibility. And maybe shutting down the AUR is the right move if the current incarnation is so bad and the people running it don’t know how to secure it.
Think of it this way - the NPM and cargo registries handle way more traffic and visibility and doesn’t have any issues like this. There they have to deal with more complicated supply chain attacks. Ubuntu and Fedora take a completely different tack with user-contributed packages that are namespaced and better sealed.
And part of this of course is that yay and ilk don’t do proper sandboxing. But that’s just more shirking of responsibility by the AUR maintainers to force the community to try to do this and failing to treat this as an end to end problem they need to own
> orphaned packages don’t need to be adoptable - doesn’t have to be a flat global namespace
Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.
It's easy to complain about other volunteers to non-profit projects are not doing enough, but truth is that there is always a lot of stuff to do as an volunteer, and while you try to fight fire X, people scream about fire Y, and vice-versa, depending on which one made the news most recently. Sure they should be scanning things, sure the official repository should be super fast and always available, sure every package should always be problem free, but it's a human project driven by humans essentially for the love of the project itself, in one way or another.
Cargo in general have the benefit of being new (shoulders on giants and so on), and being made by people who knew what they were doing. NPM has had a long struggle with a lot of stuff though, and is today maintained by one of the largest companies in the world. I'm not sure they're really comparable here.
I do agree the process for which orphaned packages get new maintainers needs to change, obviously shouldn't be possible launch such automated attack. I don't agree with that the feature as a whole should go away, I do have my own packages that depend on other AUR packages, surely many of them have through the years changed maintainer, but shouldn't mean I need to suddenly start using a different package, as long as I continue reviewing the updates.
> Those things sound worse for us who actually use the AUR the way it's meant to be used, being able to "orphan" packages for new maintainers to pick up bring us long-term stability. And since we review random 3rd party software we install from the internet, who does the actual edits doesn't really matter, as long as it's the right, simple little changes that updates usually are.
This is the problem - the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up. You’re essentially there in some ways without admitting it because of new account creation is disabled. The next attack vector will be taking over existing accounts that aren’t used.
Think of it this way - Arch is a niche distro within a niche desktop OS and still it was cheap enough of an attack that it was worth it. It’s a cultural problem and your mindset is precisely why this will keep happening. As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
> the AUR has outgrown this mindset and this resistance to recognize this fact is precisely why this problem will keep coming up.
It has outgrown the mindset that AUR is for people who use and follow the advice of Arch Linux? Or what do you mean? What I'm describing is a workflow you can apply today, apply it equally to all packages, and it stops 99% of the hacking attempts and the remaining 1% wouldn't matter if it's via AUR, NPM or Cargo, same issues remain.
> It’s a cultural problem and your mindset is precisely why this will keep happening
I agree that "Anyone can automatically take over 100s/1000s of packages as a maintainer" is a problem, I don't agree that it's a deeper problem than that. Limit each user to be able to take over one package per month, and suddenly we get all the same benefits we have already, + we fix the current issue.
No need to trash the entire AUR when there is one specific feature broken, just fix that feature, then continue your pragmatic life as before.
> As an Arch user I’m honestly embarrassed and I’m going to be looking at distros that aren’t user hostile like this.
To be fair, if I ended up misunderstand something so deeply that I didn't realize how to actually use it, I'd be embarrassed myself as well, strong of you to at least state so publicly. I'm happy you at least figured out that Arch Linux isn't for you, and you start trying to find a distribution that fits you better, rather than going through a tough period of time trying to change something into a direction it isn't even aiming for.
Installing anything from the AUR, it has always been the user's responsibility to check whatever they are installing. Has always been this way, and they have always been abundantly clear about this. It is also the reason why archlinux does not provide an official installer like yaourt or yay, they could've even built support for the AUR into pacman.
The AUR is just as safe as installing through a random shell script from github - that is to say: not safe at all.
The issue with the AUR is that its design and the way package maintainership works puts users at undue risk compared to many other "user" repositories. This happens because so many useful packages are only available in the AUR to begin with, but also because the mechanism for taking over an orphaned package is just simply too open for exploitation.
I don't have all the answers. I hope people will consider Nixpkgs as a powerful model: even though it has many thousands of PRs unmerged at any given time and requires substantial effort, it still operates at an absurd scale and yet has a higher bar to infiltration with malware, both due to build sandboxing and due to the review process. Whereas AUR maintainership is mostly handled individually per-package, anyone can submit changes to a Nixpkgs and try to get it reviewed, even if the maintainer of an individual package is long gone (though we usually give maintainers a week or so to take a look at a PR even once it has been reviewed.) This entirely gets rid of both the need and incentive to have a process to replace an orphaned package's maintainer: writing yourself in as the maintainer mostly just signs you up to get pinged for issues and PRs, it doesn't grant you special permissions to bypass the normal review process.
A giant monorepo of PKGBUILDs with a similar maintainership model plus makepkg sandboxing would be fantastic. makepkg sandboxing would be nice just for ensuring that packages correctly declare their dependencies.
I think the sandboxing thing has a better shot at actually happening, since redesigning the entire AUR around a completely different model is probably an unreasonable leap. That'd still be a pretty good improvement, though.
It seems obvious to me that they should get rid of this "orphaned" designation that allows anyone to grab a package and start pushing updates, because there's no circumstance under which that's a good idea.
I don't know how long will it take to attack also flatpak/flathub and snap stores as well.
Snap has had a couple of attacks, at least. I recall one that was a fake crypto wallet. I'm sure Flathub has, too.
That said: the attacks on Snap and Flatpak are bound to be less interesting; it doesn't share the same mechanics that make AUR scary. I still hope that Linux infrastructure vendors work to come up with good ways to "raise the floor" in these cases.
In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks. You can control the threshold since it's just user configuration now.
A bunch of common yay commands also return back the last updated time of a package thanks to https://github.com/Jguer/yay/pull/2846.
The thing is that hook is not enough: `UpgradeSelect` only applies to `yay -Syu` so it only filters the upgrade list.
Nothing protect you from a `yay -S foo` install and its dependencies. So this is not a guarantee or enforcement of a minimum release-age.
Actually writing this reply I went ahead and pointed that out in an issue at: https://github.com/Jguer/yay/issues/2883
The issue you linked isn’t anything to do with the issue you’re describing. Wrong one referenced?
Hope Omarchy will make that a default:)
Devil's advocate, except partially serious.
This is a good thing, because the warning about checking everything you download from the AUR, which has always existed, is now actually "enforced". People respond to consequences.
A lot of people in this thread seem to be treating this situation as a referendum on the security of package repositories that allow anyone to create a package. Possibly because that's interesting to more people, since npm and PyPI are more widely used than Arch.
But unless I've badly misunderstood something, the key thing that made this attack possible is this "orphaned" thing that lets you grant write access to an existing package to the first person who claims it, without any control over who that is. I don't see how this could ever be a safe thing to do, I'm not aware of any other package repository that has it, and I struggle to guess what whoever built it was thinking. If AUR just turned off that misfeature, they wouldn't be having this problem.
(The article quotes someone involved as saying that the "orphaned" feature is good because good actors can also use it, but that seems irrelevant if it also opens up an unmitigable machine-takeover vulnerability. World-writable single-namespace systems like Wikipedia work by having humans proactively checking for bad changes, and also by it not being that bad if a page is briefly defaced, since you can't push malware to users' machines that way.)
Humble question: how do you find out if your system has been affected by a malware?
I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any?
I haven't run an antivirus since I last used Windows 20 years ago.
In theory, you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens, but of course not earlier. And if your root/hardware somehow is infected, your monitoring/management tools might be affected too, so then you're basically out of luck except with external network gear outside of your computer. But then those could be infected too, and so on.
Ultimately I'd say it depends on your risk profile, but using something to actively approve/deny network connections on your local machine, is a great start that'd defeat most of these simpler "exfiltrate information ASAP" malware that seems popular at the moment.
> you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens
If you have a list of good CLI utilities, you could run them in a bash script (e.g., network-monitor.sh), which would run in the background, and then redirect the output data to another file (e.g., network-monitor.txt). The key concept here is "baseline" -- you need to know what normal baseline network activity looks like, so that you can identify anomalous behavior. The way to establish a baseline is to gather a lot of data from the system.
The following are a few useful command line utilities to use for a host intrusion detection system (HIDS) using a simple network monitoring bash script. However, I am not sure exactly how to tweak the options. Also need to find a way to check for data exfiltration:
-list open ports and processes that own them: netstat -lnp
-show open network ports: lsof -i; netstat -an | grep -i listen; netstat -nap
Then it would be relatively easy to write a python script with regex tools to parse the network-monitor.txt file, establish a baseline, analyze the data for patterns and search for anomalous behavior.
Besides network monitoring, there are other command line utilities you can use to check the system for possible intrusion, which you could run in a separate bash script as part of your Host Intrusion Detection System (e.g., hids-users.sh):
-show members of root group: cat /etc/group | grep root
-show users logged in: w #if you are the only user, you should not see more than one account logged in
-search for all accounts with UID of 0: grep :0: /etc/passwd #ideally there should be only one UID of 0 on the system, but attacker can create more.
-check that daemons who never log in have * or !, meaning no passwd: cat /etc/shadow
-look for orphaned files, possible sign of attacker temp account deleted: find / -nouser -print
-search for new user accounts that are not part of regular build: sort -nk3 -t: /etc/passwd #sort numerically third column (UID), colon delim (-t:)
EDITS: several small changes for clarity and also in response to comment below
> tail your network-monitor.txt file to watch for anomalies in the network connections and check for any strange outflows of data
Don't do that, you can't rely on "watch for anomalies" with your human eyes.
Either you setup something that notifies you after the fact, or you outright block all incoming/outgoing connections until you approve them. Mentioned elsewhere I think in the thread, I think both OpenSnitch, Little Snitch and PiHole can help you with all of these things.
But don't assume you can "watch for anomalies", automation and/or gated access is probably the way to go.
indeed OpenSnitch helps, pihole I'm not so sure (maybe if the c2c servers are in a blocklist...):
https://www.reddit.com/r/linux_gaming/comments/1u34pe3/comme...
I though Pihole could act as a "whitelist-only" DNS server but maybe I'm wrong, that could be an additional layer.
> you can't rely on "watch for anomalies" with your human eyes
Yes, I agree, that's a good call. I would not try to check for anomalies manually with meatware. I would parse the data with python regex tools to establish a baseline and search for anomalous patterns.
I edited my post to reflect the change you suggested.
Also bear in mind, that many rootkits hide processes and connections from command line tools like ps, top, lsof, netstat, ss, etc...
In this particular malware campaign, the malware contained a rootkit which hid precisely some of its activity:
https://github.com/gustavo-iniguez-goya/decloaker/discussion...
> Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any? > > I haven't run an antivirus since I last used Windows 20 years ago.
That'd be the role of an IDS (Intrusion Detection System). Things like file signatures of your entire system being saved to another machine (for example an offline/airgapped one) beforehand (for example by plugging your main machine's SSD as a secondary drive on the airgapped one).
If you suspect shenanigans, you take your machine offline, you remove its SSD (your BIOS/UEFI is also a concern), plug it to your airgapped machine with the IDS: it compares all the files (binaries, config files, etc.)' checksums with the past ones.
It's a bit of a lost art but it could make a comeback seen what we're facing, now nearly on a weekly basis.
Some distros have a way to check for file integrity as part of the package manager: but you can't trust the infos coming from the machine itself if it's been compromised.
You might start with ClamAV and something like Little Snitch.
Would love to know the rebuttal / why you were downvoted.
The AUR is effectively a pastebin for PKGBUILD files.
Some people (many of which don't even use Arch itself) have been treating and advertising it as something different. It's not a software distribution method meant for normal computer users.
And for those that aren't aware, a PKGBUILD file is just a bash script.
Note that the AUR attacks were part of the larger miasma worm campaign, gradually trying to gain more control through various package ecosystems since the RedHat prototype campaign.
Mitigation Tool: https://github.com/cookiengineer/antimiasma
Blog Post with details: https://cookie.engineer/weblog/articles/malware-insights-mia...
I love the smell of npm install malware in the morning.
Yes, feels like in those cases npm and bun are not far away. Coincidence?
Simplicity of the stack I think. I don’t think this is an npm-specific issue as the attacker could also download a bash script and run that instead.
What is a good review? Or different tiers of review? When thinking about packages, say in npm world, I still wonder about trust within nested dependencies. New users might also be unfamiliar. Any thoughts or any guidances?
I'll note that OpenSuse also has Packman which a shitton of people enable (for codecs), has also 'one namespace only' an looser policies than the main distro.
I do not think this something you can escape by switching distro.
Zypper at least has a notion of "vendor", so you can arrange things so that only the handful of packages you care about will actually come from Packman.
Ubuntu actually has first-party repositories with proprietary codecs.
Nixpkgs is a pretty comprehensive monorepo of packages with a more normal review process than the AUR, and it includes non-free software as well, plus the model with flakes for third-party stuff is that you trust individual publishers for their little repos rather than one giant grab bag repo of unreviewed content like the AUR.
RPMFusion for Fedora kinda has a similar profile, in that it's a shared repo for various things unsuitable for the main one, but it follows more or less normal Fedora packaging and review standards, doesn't it?
Supply chain attacks are possible everywhere and some distros have particular weaknesses, but the AUR really is pretty much uniquely bad here.
Nix also forces builds to be sandboxed. Now you actually need to run an infected build output to be affected.
I use Gentoo. You have to specifically install "overlays" and every package maintainer would make their own overlay. You can't easily take over an overlay without the original person's permission.
That being said, still one namespace. Once you add an overlay it can replace any package it wants.
It's also Gentoo so too hard for most people to figure out.
[dead]
Yes, the only reason this isn't happening in other distros is simply popularity.
Namespacing is the solution, and as mentioned in the article some ditros do indeed have namespaced user repos, like Fedora's Copr. The trust model of a flat namespace user repo is completely broken when the maintaining user can change at any moment.
Isn't Arch's AUR flat namespace quite unique? Ubuntu's PPAs are also not flat.
openSUSE's OBS and Gentoo's overlays aren't a single shared repo either.
Packman is more akin to rpmfusion, than AUR. OBS is the AUR equivalent for OpenSUSE.
"One namespace" is also technically true but doesn't work the same way with dnf or zypper as it does with pacman. dnf and zypper both make it easy to be explicit about the priorities of your repos and also to track which packages come from which repos and prevent that from changing. Plus openSUSE has a generously free public instance of the Open Build Service that you can easily use to host your own repos, and which hosts many individual repos you can add for specific purposes. When I ran openSUSE I always just ran my own repo there with only the extra packages I actually wanted, often just "forking" packages from repos hosted by well-known openSUSE developers so that I didn't have to manage updating the source packages myself but still didn't pull in the whole world from those repos and also didn't implicitly trust anything as loose as the AUR.
OBS is more like Ubuntu's Launchpad or Fedora's CO0R than the AUR. Random strangers can't take over the packages of others just because they go idle, and it's a bunch of separate repos, not one. Totally different trust model.
Fantastic and anti-sensationalism write-up from LWN, as usual. They continue to deserve my monies.
The funny thing is: with FOSS you know what's going on attack-wise as they are transparent , but there must be huge upheaval in the closed source (e.g. MS) software that is just kept quiet by stock-price-chasing executives.
There are automated scripts to check if the infected AUR packages are installed on your system:
https://forum.endeavouros.com/t/malicious-aur-checkup-script...
https://github.com/lenucksi/aur-malware-check
Despite that official Arch repos weren't affected in this attack, I would not recommend using Arch (or any rolling release distro) for anything that requires security. (Imagine if the xz backdoor targeted Arch...)
An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions. He only does that when the build breaks.
I can't blame him for what he did, since it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI" where more and more software are being aggressively refactored (or rather rewritten) and added more features.
What we can do is choosing a stable distro (like Debian) where packages are more thoroughly reviewed, and apply security practices (such as TOTP, sandboxing browsers and video players, etc.) even though they cause inconvenience.
I don't think Arch maintainers are responsible for auditing upstream. They package the upstream only.
If you package software for a distro, you have some responsibility for reviewing what you publish.
If you distribute an update that has malware, that is you publishing malware.
It's a complete fantasy that Debian maintainers do a thorough review of changed packages. It's not a responsibility they have, and it would be impossible anyway (how many packages are there in Debian? How many maintainers are there?).
> An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions.
Cool story bro. Assuming that's common, I have trouble understanding why Arch (non-AUR) is any more at risk than Debian--besides the latter being more popular and having more users/incidental testers, which is a real benefit if that's your goal, but has its own drawbacks (like older and known-vulnerable packages lingering for longer before updated releases are made available).
> it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI"
Aren't Debian and friends similarly at risk of this as well, then?
> security practices (such as TOTP, sandboxing browsers and video players, etc.)
I'm not sure if those are more or less prevalent on Arch; I know that many IDEs and GUI programs I've installed on Arch ran by default in Flatpaks or similar, and Debian/Ubuntu like Snaps, but I'm honestly not familiar with whether those ecosystems have significant and/or equivalent penetration in different distros.
Debian freezes the package versions on release of each Debian version and then cherry picks critical fixes for the rest of the Debian version's lifecycle. So even if they never review the code (and I don't expect them to), they're less likely to release malware before it's discovered by others.
That model is getting increasingly difficult and labor intensive, unfortunately. More and more upstream are abandoning the old school security advisories. Not many are isolating CVEs or security fixes into distinct patches, the fixes come with a version bump and often accompany new features or other bug fixes.
There's also plenty projects that silently fix security bugs without issuing a CVE or even labelling them. So now the maintainer of that packages has to monitor the commit logs, figure out if a particular bug fix has security implications and then backport it to the older version which is becoming harder and harder over time.
Unless you have a massive team or a big enough army of volunteers, the LTS model is becoming less and less viable over time, you are often safer on rolling release or close to it (something like Fedora's pace is good).
I like the Alpine model where they have a set of packages they maintain via the core team and everything else is in "testing".
You get a lower risk of them pulling in a bleeding edge vulnerability, but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue (or introduce more issues based on how they diverge from upstream).
There's no silver bullets here.
> but a higher risk that you'll get stuck with an old bug waiting for the maintainer to pull in a patch. Then there's the risk that in their attempt to cherry pick, they don't actually mitigate the issue
Which is why the whole process is open sourced and you can get easily the source version of a package, edit it and rebuild it.
> There's no silver bullets here.
Because it's a trade-off, just like stability is, they're both software bugs in the end so mitigating them has similar pros and cons.
Alarming. The whole point of official repositories is they're trusted, since they are maintained by trusted people. If one can't trust maintainers to be responsible, then the official repositories are no different than the AUR.
> where packages are more thoroughly reviewed
Where are you drawing your conviction that non-rolling-release distro maintainers are doing a more thorough review of upstream changes?
> such as TOTP
What?
there have been multiple package list checkers released, but unclear which ones are trustworthy, I can't immediately find a list from the official channels (through AUR website) to such approved scanners?
Well all of those attacks are just supply chain attacks, and it is basically exploiting people's trust. With LLMs, the speed and velocity of pumping out malice raised are now significantly faster.
It is so sad that every goodwill eventually got enshittified as well.
Who still uses Arch btw after this?
The AUR has consistently had warnings around it of 'verify the PKGBUILD', far more so than any other package repository that allows anyone to sign up. Probably the only notable difference is the ease of taking over an orphaned package.
The AUR is not the Arch package manager or repository. The main Arch package repos are managed similarly to Debian, or Fedora, or whatever--caveat Arch's nature as a rolling release, but in terms of vetting and ownership/security, the approaches are similar. pacman installs from regular, real, vetted repositories by default. pacman will never install from the AUR. pacman is the official Arch package manager and the only one that is provided with the main Arch distribution/install instructions.
The AUR is, as many others have pointed out, a deliberately un-vetted pile of random Git repos. Arch deliberately doesn't even ship with a default one-click installer for AUR packages; their published guidance is "git clone this stuff from wherever it's hosted and build it at your own risk". Plenty of third-party, non-Arch-blessed tools turn that into a one-click process, but it's not "part" of Arch itself--at least not any more than, like, curl | bash or directions on how to add rando websites to /etc/apt/sources.list.d is part of Debian and friends.
I've used Arch as a daily driver for years. At peak, I've had five (5) total packages, with no transitives, installed from the AUR. Today I have one: sublime-text-4. It's perfectly possible--and extremely reasonable for many users, even power users--to live in an AUR-less world, or to use so few AUR packages that the guidance of "read what you're installing, doofus" is manageable and not onerous.
If you want something from the AUR, just don't be lazy, read the pkgbuild.
I was not affected
Is there another distro that has an equivalent of the AUR with handling you think is preferable?
AUR is fast and loose and doesn't do much "handling" by design, so it's hard to find any equivalent repo. But there's always a tradeoff between fresh (nixpkgs unstable, might be the closest) and tested (Debian).
AUR isn't just the testing repo of Arch; it's explicitly just an open spot where anybody can put up "here's a PKGBUILD for folks". I don't see how it's like either the Nix or Debian examples.
Well, Nix has NUR which is a direct equivalent but it's not nearly as broadly used and I assume "here's a PKGBUILD for folks" is already too permissive for you if you're asking.
There's no maintainer vetting process in nixpkgs as far as I know, anyone can own a bunch of packages. There are quality standards and it's not "here's a bunch of nix code for folks" but it's the next possible thing in the line after that.
It seems like you may have mistakenly inferred that I have issues with the AUR?
I don't; I use Arch on 100% of my personal servers, have done so for something approaching 20 years, and don't see myself changing.
But I treat the AUR for what it is: a place where anybody can say "here's a PKGBUILD for folks" and it's on me to evaluate it on its merits.
I was legitimately asking the person upthread what other distro they felt had a better model for this kind of sharing, because they seemed to think this was a reason for Arch users to jump ship and I was curious what they thought would be the elements of a better system.
The NUR was sort of convenient before flakes were a thing, but now that there's a really common convention for sharing Nix code few use it. I bet most people who came across Nix in the last 4 years have never even heard of it.
No because there’s no way to handle an open submission repository at all. It’s impossible by design since anyone can submit packages to it.
I would never use anything equivalent to AUR on any distro due to the obvious security implications. That’s been my position for as long as I have known about Arch. I never understood Arch users using the AUR as a selling point for the distro.
Then again I live in the opposite end of the spectrum where I run only Debian Stable on my Linux desktop as well as my servers, where packages make it through Sid and Testing before getting to Stable and I can be relatively sure any supply chain attacks have been caught by then (like xz for example which was caught before it left Sid).
For those unfamiliar with Debian, Sid is basically a rolling release similar to using Arch with the official repositories (which is already dangerous without even touching the AUR), then packages move to Testing, then later eventually make it to Stable.
The AUR is, in my opinion, a pretty convenient selling point if you use any esoteric software.
It’s basically like a crowdsourced set of people’s tips and tricks for installing stuff on Arch, all written in the format Arch uses for packages.
Similar to how I’d not blindly take code from an AI and whack it into production, I wouldn’t blindly take an AUR PKGBUILD and execute it. But it’s nice to have a place to go see “huh, I wonder if anybody has shared their approach so I can borrow from it”.
That’s a perspective on the AUR that I hadn’t really seen before from Arch advocates, in my (admittedly hazy memory) it’s usually mentioned in the sense of “Arch is great because you always get the latest packages in the official repos and basically anything you possibly need you can just install from the AUR”. If you’re actually using it just as a reference guide essentially then it seems like there’s some value there.
However, I’ll push back a bit from my perspective as a Debian Stable user. I would consider even the official Arch repositories to be dangerous just like I consider Debian Sid’s repos to be dangerous (packages are too new and not sufficiently vetted). Then regarding installing packages not available in the main Debian repos, I’ve never really had any issues installing them either as there is always either an official developer run apt repo I can add, or an official deb package, or it just builds directly from official source without tweaks. So I’ve honestly never felt like I was missing “a crowdsourced set of people’s tips and tricks for installing stuff” on Debian as I’ve just never needed one.
I do realize that installing the latest packages directly from a developer’s repo or latest deb package or source is as dangerous as the Debian Sid or Arch official repos for the same reason (too new, not vetted), but the difference is those are only a tiny portion of the packages installed on my system (like a percent of a percent, maybe a half dozen packages out of hundreds). If I ran Sid or Arch, it would be 100% of the packages on my system which is an attack surface orders of magnitude larger.
EDIT: It did just occur to me after posting this reply that I use Homebrew pretty extensively as a package manager on macOS and its official repos are equivalent to Sid/Arch official repos, so I may be a bit of a hypocrite here :P
There are also dangers of being on older versions in Debian that rely on maintainers identifying and correctly back porting critical changes.
Fwiw the Arch docs are pretty clear that the AUR is a Wild West and that you should be vetting anything you find there before you run it.
Opensuse OBS. Tiny bit better because the build environment doesn't allow a network and binaries are not allowed as far as I know. Fedora has a similar thing COPR. Both of these support building packages for other distros as well as appimage, flatpak etc.
With opensuse official packages also use the same infrastructure. It is actually quite fascinating and powerful. (I know a lot less about COPR but I would imagine it would be equally as good. Wezterm switched to that for its packages)
Gentoo
But let's hope we get this solved, like peer review model, vouch, or something
It is very good to be able to find build/install files for everything
Gentoo's model appears to be basically the same? Like the AUR, anybody can submit basically anything they want. The requirements amount to containing valid packages, having a bugzilla account, and putting your package definitions in VCS somewhere.
In overlays that need to be explicitly enabled. Not as convenient as yay yolo.
We can also add npm to package.mask.
Yay isn’t in the official arch repos? The only way you get stuff from the AUR is by explicitly pulling down to repo and building with makepkg or explicitly finding and installing an AUR “helper”.
https://wiki.gentoo.org/wiki/Project:GURU
Windows where you just download .exe and .msi files from random websites. Not a Linux distro, but the closest security model I can think of.
You think that users having to find and download software from the Internet at large is both similar to the AUR model and has preferable handling of these issues?
Can you elaborate?
To me, installing software from the AUR sounds a lot like downloading Windows software from .info sites and torrents. It's mostly fine, but it's not exactly a surprise when things go wrong.
SlackBuilds.org is pretty sensible.
I do. I just keep reading the diffs on the PLGBUILDs.
I do, I'm just choosy about aur packages I use
I still do, I just don't touch AURs anymore.
> New user registration was stopped on June 11 and then re-enabled after the project added Anubis to try to foil the attacker's mass account registrations. That did not work
This confuses me - why would a proof-of-work anti-scraping system like Anubis prevent registrations?
Implementing a bot to do registration is not a "copy as curl " click away anymore, and creating millions of accounts maybe become computationally expensive.
This is not much, but it could deter some low effort adversaries.
I see that, but the adversary wasn’t a low effort one, and didn’t need millions of accounts.
A side note, isn't package maintenance something that can actually be solved to some extent by LLMs? The prompt would be something like "Clone this repo and build this package while building/bundling as few other packages as possible with minimal code changes."
Then set it in a loop on all the packages for a particular system, I don't have experience in package maintenance and would be curious what kind of issues would come up.
Packaging for Linux distros is about review, following standards and conventions, authority, and responsibility. (And maybe also sometimes patching for compatibility.) LLMs can sometimes help with some of the mechanical parts, but the curation and trust stuff not so much.
And everyone does this individually you mean, rather than sharing the result as 'a package'?
It's an interesting idea, not sure I'd recommend it broadly, but if someone told me they prefer to trust an LLM than third-parties I'd get it at least.