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.
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.)