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