Maybe this is a good time to try and get the top 10% of aur into official repos or 3rd party repos
As I understand it, the attack vector went after orphaned packages primarily. Several of the affected packages would only run the malicious code if it was a fresh install not an update only. So it would have had to be a clean install of an affected package or a newly installed dependency called to invoke this during the approximately 2 day window.
Yes, this is bad, but it’s clearly testing for weaknesses in the chain through AUR.
Yes, I know it’s contributed code by the community and a random actor can cause havoc. Yes, I know how to manually build packages and check for changes. Yes, I am guilty of using helpers. No, I wouldn’t catch everything on my own.
I do limit what I do use from the AUR, because those installs and updates require more scrutiny.
I am reassessing my own threat model as there’s a couple of packages where I’m dependent on the AUR - most notably displaylink drivers.
I do wish communication was better around the event. I found out first through being subscribed to the mailing list. An announcement on the main page would have gone a long way.
I know everyone say “use at your own risk,” but in practice that’s not how regular users are using npm, PyPi, AUR, Cargo and such. They’re not manually reviewing every little update to a deluge of dependencies.
…I’m guilty of this.
I don’t know a perfect solution, but it feels like this can’t go on, as package hijacking is en vogue now.
Containerization to contain damage is good, I guess, but still.
That’s a failed analogy. AUR is an end-user build-script repo, not a source/binary/source+binary repo for both devs and sometimes users.
If you e.g. install a CLI tool via cargo, there is at least an implicit tree of trust, with each dependant in a dependency tree doing at least some minimal vetting of dependencies. And the source is all there anyway (barring exceptions like
build.rspulling code or the indirection of proc macros).The same applies to npm and pypi, although there is no distinction between code and binary given the scripting nature of the languages. but there are binaries shipped with by some pypi packages (e.g. C/C++ compiled libraries). Don’t know about npm.
But, if I’m not mistaken, the py/js tooling wasn’t always there for stuff like full pinning of dep versions like cargo, and that’s a very important technical detail.
With the AUR, there is no trust tree. And often no fixed code (or binaries) to look at (e.g. *-git packages). So the feasibility of doing any sort of global in-tree checking/vetting is not there. On the other hand, source repos are responsible for removing, or at least flagging, malware or otherwise harmful packages once that becomes known.
Incidentally, I commented on both AUR security and cargo trust here and here. So, I will stop blabbing.
The article mentions the potential need for human review. I have no idea how that could be feasible for something as massive as the AUR. Maybe it could work like Nix, where every package goes through a PR/MR process, and then after it gets approved, the submitter is added to the list of contributors. It’s definitely not a perfect process, but it’s better than the zero-review process that the AUR has.
I’ve noticed some installers have at least a voting system (e.g. Octopi) which helps… slightly. At least in knowing what the right package name probably is. Crowd source reviewing is probably the only option for such a vast and open system, even if it can be gamed sometimes.
imo, there should be automatic tags like “active”, “abandoned”, “maintainer changed recently”, “updated after hiatus” and a few more.
The arch devs and community can decide on the time frames. It’s not going to be perfect, but it may help warn users of the changes and so they can do a double take.
Anything other than the “active” ones should show what changed (paru already does this) and users should make a conscious choice to install it anyway. (y/N) instead of going through the installation spamming the return key.
AUR does have a voting system, albeit a basic one.
It is my speculation based on experience and direct invitations to review stuff that Google effectively does ranked crowd-sourcing for Google Maps, etc., in which Google secretly tracks and gives heftier vote power to veteran accounts with longer histories of competence and reliability (especially, say, accounts that are a decade old and still regularly contributing and proposing corrections), unbeknownst to said account holders themselves. Perhaps their lead could be the way out of such messes.
Just be aware that the AUR is not vetted. Its like downloading random stuff of the internet and then install said stuff. Always check your sources.
I was thinking that too, like downloading random .exes and complaining your Windows got a virus. At least now a days, Windows .exes have a signing process that warn you, but that’s just like using non-AUR sources; they’re verified.
But we like Linux because it doesn’t give you a big scary full screen warning every time you try to open something… so IDK. If that’s what you need to keep you from installing malware, get off Arch.
That’s not why I like Linux… but on that note anyway: if the source providing said warning is trustworthy, then let’s have it!
I use malware, BTW.
I’d love to know what’s going on with this. Arch has its haters but someone’s putting a lot of effort into this
It seems like some person with a bot just asked to maintain a bunch of orphaned packages, abusing the 2-week waiting period. Right?
Thats why they used npm; off the shelf, almost “standard practice” credential harvesting malware. Nothing too fancy.
ok, time to completely stop using AUR.
I’ll only manually git clone packages
