5 ms·

People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. You have to review the source of every PKGBUILD from the AUR

• Vexs 4mo ago
  > You have to review the source of every PKGBUILD from the AUR you install, full stop I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either.
  • kpcyrd 4mo ago
    This is an "in addition to" problem though, not an "instead of" problem. Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
    • dsp_person 4mo ago
      Also have realized at some point that reviewing the PKGBUILD and code in github repo still doesn't check whether the github release files are compromised.
      • backscratches 4mo ago
        Build it yourself or bust
      • deleted 4mo ago
        [deleted]
      • deleted 4mo ago
        [deleted]
  • jolmg 4mo ago
    > it's not really viable to audit the entire dep chain by hand When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc. Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.
  • JeremyNT 4mo ago
    > I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either. This is different though. The attackers of the AUR don't have access to do anything to upstream and any malicious dependency they add would have to be either 1) already built as an official package or 2) also taken from the AUR... in which case the person building it would need to audit the dependency as well. So you have two "AUR hygiene" principals at play: One, know what software you're even installing, and Two, know that the PKGBUILD does what it says on the tin. If you neglect either of these and YOLO then it's kind of on you. Arch users should really know that the AUR is something to approach with a massive amount of caution. It's better than "curl bash" from some rando web site, but that's only due to the fact that you can easily audit and diff the payload of the install recipe yourself.
• 2OEH8eoCRo0 4mo ago
  Why does nobody act like it is then? I don't use Arch but every Arch user talks about the Aur so matter-of-factly yet nobody treats it with the caution that it demands.
  • Semaphor 4mo ago
    They do? Arch exploded in popularity, but the forums were full of warnings. My favorite Aur helper (pikaur) also asked you to check the PKGBUILD on every install or update, back when I used Arch.
  • keyringlight 4mo ago
    My sense of it is that as linux is gradually inching towards the general power user audience, there's a lot of "just use [distro]" or fashionable distros where they're all seen as flavors of one thing. In a sense that's true, but not in others like this. I'd also add the various atomic distros like Silverblue or derivatives which have other conditions you need to learn to work with. For AUR it seems to get recommended as a secondary way to get software, if it hasn't been brought into the original distros package repos then the next step is to just search AUR, make the shortest line to the goal and don't worry about the details. As far as Arch goes, I wonder if Arch-based CachyOS is a factor as it's seen the high performance desktop linux.
  • backscratches 4mo ago
    Every single app you've ever downloaded basically shares this same property. You either audited the code and know what it does or you are taking someone's word for it.
• VladVladikoff 4mo ago
  >You have to review the source of every PKGBUILD from the AUR you install, full stop Believing that even a small fraction of users actually do this is deeply detached from reality.
  • darkwi11ow 4mo ago
    I use Arch on my dev qemu VM and actually review all changes all the time. It is not that hard with small amount of pkgbuilds: find ~/.cache/yay -maxdepth 1 -type d /home/virt/.cache/yay /home/virt/.cache/yay/google-chrome /home/virt/.cache/yay/ngrok /home/virt/.cache/yay/rancher-k3d-bin /home/virt/.cache/yay/simplescreenrecorder /home/virt/.cache/yay/ttf-comfortaa /home/virt/.cache/yay/cursor-bin /home/virt/.cache/yay/yay /home/virt/.cache/yay/volta-bin
  • worble 4mo ago
    And most people don't ever check their car oil. The point is that the onus is on you to do it, and if you don't then the consequences are yours to bear. Personal responsibility seems to be in short supply these days.
  • drankinatty 4mo ago
    "Review every PKGBUILD" is as realistic as expecting the EULA to be completely read and understood (including the forced arbitration clause) before clicking "I Agree". It also ignores the poor souls using AUR helpers that automatically download and build packages from AUR as they were designed to do for the convenience of Arch/AUR users. AUR isn't just some download site. It has been actively marketed by Arch for at least the 17 years I've used Arch as it's user repository. (that's kinda the acronym) That creates the expectation, rightly or not, that the Arch User Repository provides some degree of protections for Arch Users against the build sources hosted there being compromised. The AUR is a great resource for Arch and the wider Arch community and it was put together by some really talented folks at a time when the threat environment was completely different. Times have changed, and it's a sad testament for humanity. AUR will get through this, and be better for the additional guardrails to be put in place, but blaming the victim and CYA never gets you there.
• no-name-here 4mo ago
  > You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?) Maybe it’s not the case for aur, but the others could theoretically be improved with better permissions, sandboxing, etc. I guess browser extensions basically have those options, even if no “normal” users use them. Unfortunately 99.99% of people can’t or don’t have the time to review everything. :-( I guess distro packages where there are trusted maintainers, or places like the iOS App Store where there are both permissions and somewhat of a review process, are the safest.
  • codemac 4mo ago
    > isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD. The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.
    • DavideNL 4mo ago
      Curious, in this specific case: if people DID review the PKGBUILD, what exactly would they recognize to spot these packages were compromised ?
      • Matl 4mo ago
        Some things I try to check for - sources array has sources that don't correlate to the package name/purpose or are from strange places, like github repos that don't seem relevant etc. - extensive post install scripts suggesting it's doing a lot more than is normal But those are very crude, I wonder if an AUR helper could optionally consult a local LLM to review a PKGBUILD before installing these days...
• tetromino_ 4mo ago
  > I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time. Even the most primitive LLM review workflow would have caught this compromise. Adding or modifying any invocation to a PKGBUILD that may download something from the network and execute it (whether using npm, pip, curll|bash, or whatever else) -> automatically quarantine the PR and flag for 2 human reviews required. Same for anything that looks like obfuscation. Same for anything that adds dependencies on the wrong language ecosystem (like new use of javascript ecosystem tools in a c++ based package). I have no idea why they don't do this already.
  • Tharre 4mo ago
    Any and all modifications to PKGBUILDs may download something and execute it, that's the very purpose of PKGBUILDs, to download and install new software. I'm sure it would be great to have trusted reviewers look over every update, but the simple reality is that all of this work is done by volunteers and there isn't nearly enough manpower for it. Maybe doing automated LLM reviews would help, but this is a large infrastructure investment. And it's not clear that it helps at all, after all models are quite vulnerable to prompt-injection type attacks.
    • porridgeraisin 4mo ago
      I have LLM operate yay on my machine before installing and read PKGBUILDs and summarise it for me and I look through the weird ones and only then do the actual upgrade. Maybe we can make an aur helper that is wired up to deepseek :D
    • tetromino_ 4mo ago
      > Any and all modifications to PKGBUILDs may download something and execute it A normal PKGBUILD should not download anything programmatically. It should rely on the package manager to download the files listed in the PKGBUILD's source array. If a PKGBUILD is running a command to download something not listed in source, that's a sign that something nefarious could be happening, and such a PKGBUILD absolutely requires careful human review. > all models are quite vulnerable to prompt-injection type attacks A less than 100% reliable mechanism sure beats the current situation which is "wait for users report on the forum that they have been pwn3d". May I remind that this is the third time AUR-hosted PKGBUILDs have been compromised?
• gqgs 4mo ago
  Regardless of it being just a collection of user-produced PKGBUILDs the community would certainly benefit from a more robust solution to this issue. Expecting users to manually review every single change, for every single AUR package they are using, every single time they do an update or installation is just unreasonable if you want to AUR to be useful at all for the general user.
  • Foxboron 4mo ago
    > Expecting users to manually review every single change, for every single AUR package they are using, every single time they do an update or installation is just unreasonable if you want to AUR to be useful at all for the general user. How many AUR packages are you assuming people are installing?
    • gqgs 4mo ago
      Could be one or one thousand. Frankly, the exact number doesn't matter. I'm assuming people are using the AUR to install programs that are sufficiently complex and the idea one can trivially audit a complex program and all of its dependencies is foolish. The foolishness of that expectation scales with the number of complex programs installed. The idea that users should "just check the source code every single time" has never been, nor will it ever be, a reasonable solution to supply chain attacks.
      • Foxboron 4mo ago
        > Could be one or one thousand. Frankly, the exact number doesn't matter. It does. Manually checking a couple of AUR packages is easy. Installing a thousand AUR packages is not something anyone should be doing. > I'm assuming people are using the AUR to install programs that are sufficiently complex and the idea one can trivially audit a complex program and all of its dependencies is foolish. The foolishness of that expectation scales with the number of complex programs installed. Nobody is asking them to do that. The premise is that the `PKGBUILD` and auxillary files provided by the AUR should be checked. > The idea that users should "just check the source code every single time" has never been, nor will it ever be, a reasonable solution to supply chain attacks. Again, nobody is asking anyone to do this.
• j-bos 4mo ago
  Yeah, I don't even use the AUR. If I need something, I'll just build it myself. Convenience is dangerous.
  • Ferret7446 4mo ago
    > If I need something, I'll just build it myself That's basically what the AUR is.
    • j-bos 4mo ago
      Except for the "you"rself part.
      • j-bos 4mo ago
        In that the AUR involves running a build command and scripts that you didn't put together.
• carlsborg 4mo ago
  > AUR is just a collection of user-produced PKGBUILDs. Is that much different from the entire pypi ecosystem, and npm, and dockerhub (people disable Selinux, --privileged turns off seccomp and apparmour, sandbox escape CVES exist)?
  • thewebguyd 4mo ago
    Not much different no, and people have equally bad practices around programming package managers as well. The entire dev ecosystem has terrible security hygiene, largely because of the pressure to move fast and real security controls by their nature limit flexibility and can slow most processes down.
• nubinetwork 4mo ago
  > People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. While that may be true, is the AUR not moderated or operated by arch devs? On Gentoo, I can't just push "npm install malware" to 400 packages in guru without someone else's approval. > You have to review the source of every PKGBUILD from the AUR you install, full stop. With a semi official repo, I would expect the people with push access to not upload malicious packages... while its still possible, and things do happen, completely pointing the finger at arch users for simply using arch isn't very helpful.
• m463 4mo ago
  I should mention - if you follow the instructions on the arch wiki to use the AUR the instructions tell you not to trust things. That is the burden of arch linux, and the beauty. you have to go through it and you have to learn. Now just hoping that people are reading (and learning from) the arch wiki going forward, not just agents. sigh. hmm... I guess people insulate themselves after a while with stuff like yay
• cncjvu7 4mo ago
  > All of that being said, the era of allowing anyone to adopt AUR packages might be coming to an end. Should have never been a thing. I hope we end up with something more like username/packagename-bin|git That'll make it way more obvious to people what they're really installing and from who.
• sd1010 4mo ago
  Arch itself is just a collection of user-produced PKGBUILDs. It's provided without warranty (like any GPL code). The difference is that Arch got a trusted reputation throughout the years, while in AUR even the packages that also have a reputation can suddenly change their owner - which produced the current issue.