5 ms·

As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily

• dbgobrrr 5mo ago
  > users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. I think this stance should be re-evaluated. Arch Linux developers are doing a fantastic job and I am personally thankful to them - this is not in any way critical of them. And while I don't see an easy solution here, I just feel that the time of "warning users" is long gone with how much supply-chain attacks are ramping up these days. Some other controls could at least alleviate the problem. Perhaps some form of peer-review and grace period before publishing could help here?
  • embedding-shape 5mo ago
    Personally, what you suggest would defeat the purpose of the AUR, and what you describe is already applied to the official packages. If you want only the safe and stable stuff, don't use random packages from AUR :)
  • anon7000 5mo ago
    Idk. Arch does have official repositories that are actively maintained and vetted. AUR is for the vast amounts of random software that isn’t popular or important enough to be officially maintained. I’m not sure how to find a balance. One reason to use Arch is to always have the latest software, especially if you’re gaming. (Need to run very recent kernels, GPU drivers, and DEs to support new graphics cards.) So that’s very different from other stable LTS distros which carefully pick the package updates they incorporate. Anyways, I do agree package cooldowns and such make a lot of sense. Package managers should be pulling out the stops on all the free controls they can implement. I can understand why anything requiring compute or maintainer time is a non-starter. (Sidebar: I don’t feel the same way about npm. Microsoft can afford to run malware scanners and analysis tools on npm packages.) https://wiki.archlinux.org/title/Official_repositories https://wiki.archlinux.org/title/Official_repositories
    • beej71 5mo ago
      There's some big stuff in AUR like the binary VS Code and Chrome, fwiw.
      • newsoftheday 5mo ago
        I'm on Kubuntu and I install VS Code using Microsoft's repo and Chrome using Google's repo. Also I do Wine and Docker using their own repos. I can't imagine VS Code or even Chrome being put into the mainstream Kubuntu/Ubuntu repos nor why such a burden should ever be shifted to Canonical.
        • tjoff 5mo ago
          Since you are using the official repos thats not an issue. The issue is when the package creator is some rando on the internet.
        • vlovich123 5mo ago
          That’s because you’re using something those companies officially support. Is your argument everyone running Linux needs to be on a Debian-based or Fedora-based distribution? Btw the official “vscode on Linux” instructions literally point to the community maintained AUR (same for nix). The truth of the matter is the AUR is poorly maintained structurally, regardless of what companies officially support. Things like letting arbitrary people unilaterally take over orphaned packages is horrendously stupid.
          • sam_lowry_ 5mo ago
            Stupid or rather low-friction on purpose?
            • emsign 5mo ago
              Both. And that's an even worse combo, making stupidity frictionless.
            • 5mo ago
  • mcv 5mo ago
    It's definitely a sign that popular packages should be moved from AUR to the official repository. I've got some stuff from AUR simply because it's something I need and that's where it is, and I never really verify it's safe; I just trust it blindly. Clearly a bad idea. I guess I should learn to avoid AUR and when I do use something from it, we more aware it's an exception and I need to check it more thoroughly. That's something I normally only do only for stuff that's neither from AUR nor the official repo.
    • axus 5mo ago
      How much work is created (and for who) when a package is moved to the official repository?
      • homebrewer 5mo ago
        A package maintainer has to be interested and willing to support it. Sometimes packages get dropped from the official repositories into AUR when the maintainer loses interest, and noone else wants to pick up the slack.
  • thewebguyd 5mo ago
    > Some other controls could at least alleviate the problem The biggest one I'd suggest they change immediately is remove the ability for anyone to just take over an orphaned package. That's a crazy policy, to me. It should require you to fork it & resubmit, not take over the original. Then they can go through and do purges of orphaned packages that are beyond a certain age.
    • xnzakg 5mo ago
      How would this help against someone submitting an actual, non-compromised version bump, then adding malware once it's accepted?
• cge 5mo ago
  >`rua` and other similar CLIs make it really easy to review the packages before installing them from AUR too, and if you are doing banking on the same computer, you really have no excuse not to review the software you depend on. What review should users do? It appears that, in some cases, these were adding npm as a dependency and installing atomic-lockfile, and in others, these were adding bun and installing js-digest. This was a mass attack against mostly low-use/orphaned/etc packages where maintainership was taken over or a different user uploaded a new version (itself a very simple, low-notice, low-oversight process), and many of the packages clearly had no connection to Node.js at all, so a user who knew enough about each package, and knew what npm was, might notice the oddity in the package, if they reviewed every line of the PKGBUILD, then reviewed the install scripts. But legitimate AUR packages for packages connected to Node.js also use npm, for example, and at times, use npm install. A user would have to be familiar enough with Archlinux's build system to understand the difference between each part (eg, build() vs install scripts). They'd have to review every PKGBUILD, every install script, and every patch of every AUR package they install. For packages that actually do use npm/bun, they'd have to be familiar enough to know what uses were legitimate and what uses were not, and might have to be up to date on compromised dependencies. And this is still considering a mass attack that was not particularly hidden. Attacks could be made much harder to find. Asking a user to safely review an AUR package essentially seems like it is asking them to fully understand not just the build process, and programming language, of the upstream package, but also all details of Archlinux's build system. They need to learn how to do this with, as far as I can tell, no real guidance: AUR itself, and the wiki's page on it, just warn that users should carefully review the PKGBUILD and install scripts, without giving any substantial guidance on what to look for or how to review anything. The warnings feel much more like liability-reduction than an attempt to be helpful. At that point, what is AUR actually offering that installing the upstream package isn't? It feels like the suggested 'safe' way of using AUR would make it just as much work for the user, and require just as much knowledge, as either installing the upstream directly, or even making a package for it. There is perhaps some room for LLM analysis here: Opus 4.8, Kimi latest, and even Qwen3.6 27B quickly catch at least the current round of malicious packages in my tests. But a motivated attacker could make that more difficult, or dangerous. And a user could also just have those models install the upstream package, with less risk. If they want to use pacman for management, they could likely even have those LLMs generate a package, with less risk.
• mcv 5mo ago
  It's still surprising someone was able to infect so many packages. But I admit I don't really know how AUR works. Can anyone with access simply update anything? Do packages not have owners who check contributions?
  • jorams 5mo ago
    Packages in the AUR have some number of maintainers. When a maintainer no longer wants to maintain the package they can disown it, and when all maintainers do so the package becomes orphaned. An orphaned package can then be adopted by any user. At any time there's a large number of orphaned packages in the AUR, and the attacker(s) targeted those.
    • Slothrop99 5mo ago
      Obviously way too easy to take over these 'orphaned' packages if it can be done in an automated manner. GitHub/NPM/etc doesn't have this issue, they need to stop equivicating. Sounds more like an anonymous FTP site.
    • mrbluecoat 5mo ago
      This. Who needs social engineering NPM maintainers when there are thousands of freebie AUR ones.
  • embedding-shape 5mo ago
    > But I admit I don't really know how AUR works It's basically GitHub (in terms of "User's generated content") but tailored and specific to Arch/Arch-derived distributions. Packages have owners, but everything is very "freeform" in general on the AUR. It wasn't uncommon you could be added as a maintainer by just sending a mail to the current maintainer, since it's basically "Hey let me contribute to your repository" (simplified), today people keep track a bit better and avoided that I've seen. But still, it's on a individual basis. Just like GitHub, AUR is completely devoid of peer-reviews, users uploads their own PKGBUILD and share with others, and the expectation is that users review stuff before they install it, just like on GitHub, or just like on the internet in general.
• cosmic_cheese 5mo ago
  I think it’s a great argument for some combo of immutable system files, installation of packages as user-local by default (making elevated manager privileges unnecessary), and components and programs being given as little privilege as possible by default. There’s bits and pieces of this in place with immutable distros, Wayland, and Flatpak but notable holes remain. The biggest one is that sandboxing is tied to the package format which I think is a mistake. Sandboxing and access permissions should be a system-level thing so even arbitrary binaries can’t easily slip through the cracks. This wouldn’t fix the problem entirely, but it’d greatly limit the blast radius and make users of the distribution a less juicy target.
• stbenjam 5mo ago
  "Review" them how? Read every single line of code before installing something? If it's a binary package, how do you do that? Make reproducible builds for everything you install? Move to from source distro? Putting this on users is not a tenable solution. There's room for common sense, but blaming the users for this is ridiculous
  • t-3 5mo ago
    An archlinux package build file is just a shell script. It's pretty easy to take a look and see if all the manifest info is right and it doesn't do more than ./configure; make; make install DESTDIR=$PKG or whatever. If you're building random software using random instructions from the internet and don't make sure they're not malicious, you only have yourself to blame when you catch something. Actually reading through the source files for vulns is something best left for automatic detection, checking the build script is basic.
    • bethekidyouwant 5mo ago
      How is that relevant unless you read the make file?
      • embedding-shape 5mo ago
        If you don't trust upstream, a PKGBUILD from AUR is the least of your problem.
  • kcyb 5mo ago
    As an arch user, I would always skim the PKGBUILD file of AUR packages to see if they install the software they claim to install from official sources and if there's something obviously fishy.
    • echelon_musk 5mo ago
      I'd be surprised if you did it as a Debian user!
    • 5mo ago
• -mlv 5mo ago
  I recall the AUR always being touted very highly as some great advantage for Arch as a linux distro, unfortunately this convenience has also come with a price. It's crazy that all it takes to become a maintainer of a package is to flag it as orphaned, wait 2 weeks for the original maintainer to fail to respond because they're on a holiday, and BAM! - the attacker can gets assigned as a maintainer and can now ship spicy updates.
  • dualvariable 5mo ago
    That is a terrible way to run a package repo in this day and age. Maintainers need to have some level of vetting, and should own a repo or three for a while to establish a track record, before they get to blast out contributions to 100 of them without any review.
    • Gormo 5mo ago
      AUR isn't a package repo. It's a collection of user-contributed PKGBUILD scripts, to make building packages from upstream source distributions more convenient. It's not meant to be treated like an official repo of binary packages.
      • dualvariable 5mo ago
        That's a semantic detail based on the choice of build from source over binary distribution. This is also a terrible way to run a package build system in this day and age as well, if you like. I feel exactly the same way about it, and when I wrote that I understood what it was, so I didn't need that helpful correction (I first used the FreeBSD ports system sometime around the turn of the millennia).
        • embedding-shape 5mo ago
          > That's a semantic detail based on the choice of build from source over binary distribution. It's not, AUR is more like GitHub, anyone can upload content there, not like a proper repository where things are reviewed, verified and cared for. You're complaining about "curl https://random-website.com https://random-website.com | bash" being "a semantic detail" while it's a major difference in how much trust you can put into it. If you don't trust random-website.com, you shouldn't trust AUR packages. But very different from BSD Ports or Arch's official repositories.
• glitchc 5mo ago
  This is great but ultimately unactionable advice, which makes it worse than useless because it sounds good at first brush but upon inspection turns out to be ridiculous. There is more code out there than is readable by any human being in their lifetime. I'm willing to bet you yourself have read <1% of the source code currently running on your computers. Does this mean you have stopped using your computer(s)? How can you trust anything that happens on them?
  • sam_lowry_ 5mo ago
    As someone already explained in a sibling comment, Arch Linux AUR packages are simple shell scripts that download source code from upstream, apply patches and install. I review them every time I have to install from AUR.
    • bawolff 5mo ago
      And what if upstream is problematic? Even if it stops this particular attack, reading just the AUR file feels like fighting yesterday's war. I don't think advice to the effect of, just read the parts of the code that have been used in attacks in the past but blindly trust everything else, makes a lot of sense.
      • Hackbraten 5mo ago
        > And what if upstream is problematic? Then don’t install the package. It’s on you to decide whether you trust upstream or not. You’re free to use any scanner you want on the upstream sources if it makes you feel safer. (I’m currently working on a makepkg extension that allows just that.) The core and extra repos are curated, and every package maintainer is doing their due diligence (and more) to protect the users. But on the AUR, nobody is going to do that work for you.
        • exceptione 5mo ago
          > doing their due diligence (and more) Do you know how? This sounds like an unpractical high amount of time consuming task.
• Gud 5mo ago
  So easy to say. For a distro this popular I’m surprised how much is in unofficial repos(AUR) and not the official ones.
  • deleted 4mo ago
    [deleted]