17 ms·

Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

319 points by qwertox 4mo ago

embedding-shape 4mo ago
As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. `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. Keeping the amount of packages low, only use what you need, also makes this a whole lot simpler when it's time to upgrade.
- dbgobrrr 4mo 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 4mo 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 4mo 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 4mo ago
      There's some big stuff in AUR like the binary VS Code and Chrome, fwiw.
      - newsoftheday 4mo 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 4mo 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 4mo 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.
  - mcv 4mo 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 4mo ago
      How much work is created (and for who) when a package is moved to the official repository?
      - homebrewer 4mo 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 4mo 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 4mo ago
      How would this help against someone submitting an actual, non-compromised version bump, then adding malware once it's accepted?
- cge 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
      This. Who needs social engineering NPM maintainers when there are thousands of freebie AUR ones.
  - embedding-shape 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
      How is that relevant unless you read the make file?
      - embedding-shape 4mo ago
        If you don't trust upstream, a PKGBUILD from AUR is the least of your problem.
  - kcyb 4mo 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 4mo ago
      I'd be surprised if you did it as a Debian user!
    - 4mo ago
- -mlv 4mo 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 4mo 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 4mo 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 4mo 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 4mo 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 4mo 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_ 4mo 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 4mo 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 4mo 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 4mo ago
        > doing their due diligence (and more) Do you know how? This sounds like an unpractical high amount of time consuming task.
- Gud 4mo 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]
tryauuum 4mo ago
How bad was it?
- graemep 4mo ago
  1,500 packages out of 107,000 so pretty bad, ameliorated by only affecting installs of those in a window of a few days. AUR comes with a warning that its up to you to check what you install from there.
  - __s 4mo ago
    I was concerned at headline, then saw "oh just AUR" Next up, "millions of malicious packages still not taken down on internet"
  - maxerickson 4mo ago
    I wonder what typical AUR usage looks like. I apparently have 27 packages installed and last updated one in November.
    - TomK32 4mo ago
      There's more than one way but this lists packages not installed by pacman itself: pacman -Qm Only 237 on my 12 year old system but I rarely update AUR packages and usually try to remove unused ones before updating.
anthonj 4mo ago
I cringed hard when some people started to make pacman wrappers that could install from AUR directly. I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.
- mqus 4mo ago
  This sounds like your update process is quite involved then. Or do you just not do it?
  - anthonj 4mo ago
    I only have a couple of things in /opt/ and some manually installed fonts, and vim plugins in my home. Everything else that I don't use often lives in the original cloned git repo in /home/projects and never really gets installed. Of course the process breaks down for a large amount of packets, but I've never been in that situation. In part because the official repo is already large, and in part because I like minimalism. If that even became an issue, I would manage a personal set of pkgbuild probably.
- Grombobulous 4mo ago
  For me, this tradeoff isn’t worth it. I didn’t switch to Linux so that I can waste time going to websites and clicking “download” to update my programs like a Windows user. The pacman wrappers you mention are crazy, though.
  - anthonj 4mo ago
    I get it, but you only need to do that for the odd cases of packages not present in the official repo (not that common at all for me at least). Also if the software is downloaded in the form of a git repo, you only needed to checkout the new tag and rebuild, don't need your browser at all.
    - 4mo ago
new_usemame 4mo ago
[flagged]
Havoc 4mo ago
As I undertood it this was mostly orphaned packages?
- Shank 4mo ago
  That's correct, orphaned packages could be adopted seemingly automatically, so someone did and then published malware in bulk.
  - beej71 4mo ago
    This makes me want to adopt more packages. Lots of the orphans barely need updating.
- gbin 4mo ago
  Yes and honestly super kudos to paru's creator for the nagging warning about installed orphan packages that made me remove them immediately. So with a dozen of various systems running arch/cachyos for various purposes, 0 impact. We seriously dodged a bullet though, should we have some kind of AI spotting shady activity before it hits the userbase?
- ajross 4mo ago
  Not even "packages" in the distro sense. You can't use software installed with Arch to install this stuff via any path that isn't isomorphic to rebuilding the package yourself. This was the AUR repository, which is the community-maintained soup of non-distro packages. They're packaged using the same tools and technology, with the intent that they can be easily validated and promoted to core stuff in the future. But they aren't really "Arch Linux". You need to deliberately enable and install tools to pull stuff from it. Think of this as Steam or Chrome. You can install those on Arch, and people do, but if Chrome extensions or Steam games suffer an incident like this you don't blame the distro.
  - cge 4mo ago
    > They're packaged using the same tools and technology, with the intent that they can be easily validated and promoted to core stuff in the future. That's perhaps the intent ideally, but in practice, it feels like AUR tends to be (a) niche, esoteric things that will never be anywhere outside of AUR, even if they could, or (b) installation methods for proprietary/otherwise non-open packages that can't be. The latter seems to a major popular use of AUR: sorting packages by popularity or votes comes up with lists that seem to be mostly these. And that's likely a significant draw for non-technical users. If you want to install things like Dropbox, Chrome, VS Code, Minecraft, Zoom, Slack... they all show up in AUR. By their nature (usually extracting packages from upstream installation methods), they tend to be more complicated than generic AUR packages. They are also often quite a bit more convenient than using the upstream packages, which might not interface well with Archlinux, might only be available with installation methods that clobber things, might be deb/rpm only, etc. I wonder if it would make sense to have a more trusted/vetted repository of these sorts of scripts, separate from core repositories but also not as free-for-all as AUR. That might go a long way toward keeping non-technical users from being drawn to AUR.
robby_w_g 4mo ago
I’ve made a point of not installing any AUR packages. It’s really tempting when there’s a package that’s not available via pacman, but at the end of the day I’d rather build from source myself or use a docker image.
- anothermoron 4mo ago
  Sadly they forced anybody with an older nvidia gpu to use some AUR package some months back.
- popcornricecake 4mo ago
  I've made a point of always installing software via the package manager. That means making my own PKGBUILDs if there's not already good ones available. I don't want to ever sidestep the package manager and go `sudo make install` or something. That feels like taking a shit in your system directories and you'll never be able to clean it all up after a short while.
bitmasher9 4mo ago
I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?
- graemep 4mo ago
  Arch is fine if you do not use AUR. If you use AUR check everything. Most distros are too. All the big distros have pretty good track records.
- fooqux 4mo ago
  The AUR is user supported and thus malware sneaks into packages all the time, although admittedly not to this scale. Still, it's pointedly not secure and has always had "here be dragons" signs plastered all around it.
  - bitmasher9 4mo ago
    That’s not so much an example of who is using best practices, as it is an example of who is using worst practices.
- halfcat 4mo ago
  > Who is doing package management right these days? Who is doing it securely? QBASIC. When you need a package you type it in from a magazine. Virtually anything you could ever need is only 1-12 weeks away.
  - vunderba 4mo ago
    QuickBasic, the commercial version of QBASIC, also supported BI files. These could be used to bundle shared code for things like high-precision timers, interrupt usage, etc.
- anon7000 4mo ago
  There are definitely LTS distros where the official packages are not updated ASAP. Npm lets package authors publish new versions to all users immediately. Anything that doesn’t allow that is better. Some distros only incorporate patch/security updates for example. AUR is worse, in that there may not be official authors and you can take over releases of a package. Like, you’ll have random users publishing the release for some application that doesn’t have their own Arch release. And if that user disappears, someone else may take it over
w4yai 4mo ago
"linux has no malware, windows bad boooh"
- dist-epoch 4mo ago
  "linux has a central package manager with every app that you need, so you don't need to install random apps from random websites like on windows"
  - w4yai 4mo ago
    > central That will end badly at some point
rvz 4mo ago
Who's on Arch Linux btw?
mkayokay 4mo ago
So from a quick read, it seems it installed "atomic-lockfile", "js-digest" or "lockfile-js" from npm. A list of affected packages is here [1]. Didn't find any quick info on how to check a system, so I ran the following command to find foreign packages and some date related infos: > pacman -Qmi Check the output against the list of affected packages. Then, you can also grep for those files in various locations: > grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json" > grep -rl "atomic-lockfile" ~/.npm 2>/dev/null > grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null Don't know if the packages delete themself after they run. I just wanted to provide some basic commands, as all the other infos I found didn't provide any help. [1] https://md.archlinux.org/s/SxbqukK6IA https://md.archlinux.org/s/SxbqukK6IA
- DavideNL 4mo ago
  Also see: https://github.com/lenucksi/aur-malware-check https://github.com/lenucksi/aur-malware-check
- jeroenhd 4mo ago
  The attacker used at least three Node dependencies in the attack, just checking for atomic-lockfile is not enough. The names js-digest and lockfile-js were also used, and at some point the attacker switched to bun instead of npm.
- stefan_ 4mo ago
  I love that even when trying to put malware into Arch Linux AUR, the malware is still distributed through NPM. Legendary platform.
- shlip 4mo ago
  Here is how I did it : Get a list of installed packages originating from AUR using 'yay' : yay -Qam > packages_aur.last Get list from https://md.archlinux.org/s/SxbqukK6IA# https://md.archlinux.org/s/SxbqukK6IA# : curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt then : grep -wFf compromised.txt packages_aur.last should spit out the packages that are in both files, hence were compromised at some point, I guess.
landdate 4mo ago
> It was bad enough when finding out more than 400 AUR packages for Arch Linux users had been infected with malware but now that number has risen to around 900 a few hours ago and now in the end at more than 1,500 user-contributed packages.been infected with malware I never had a need for the AUR. If I want a package not in the official repository I build it myself or if it has a binary release I will download it. this way i don't have to use root when building and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases. At least in this way there is one less level of possible malicious code insertion in developer -> user, vs develeper -> maintainer -> user.
- well_ackshually 4mo ago
  [flagged]
- NekkoDroid 4mo ago
  > this way i don't have to use root when building `makepkg` will actively refuse to run if you are invoking it as root (unless you specifically invoke it with something like `env EUID=123 makepkg ...`). > and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases. I do wish pacman would support a user level installations. It will refuse to install packages as non-root (which you can go around by using user namespaces and mapping yourself to root).
  - landdate 4mo ago
    Maybe I used imprecise wording. Not root, but must be part of sudoers. Or am I misunderstanding how the process works? Don'tWhenever I have installed a package from aur with yay it requires user being part of sudoers.
    - NekkoDroid 4mo ago
      Yea, but that is to install the package after it was built (or installing dependencies). The build itself is done unprivileged.
28304283409234 4mo ago
Could we be heading towards a world where it's just more secure to write inhouse software again, only now with AI agents? Not closed source per se, but 'own source'?
- dontfeedthemac 4mo ago
  this
- jl6 4mo ago
  The endgame is to generate a binary image for an entire single-purpose OS/unikernel that does exactly and only what you require of it. No source to open or close.
  - ianburrell 4mo ago
    The build process is just as vulnerable.
    - jl6 4mo ago
      Sounds more midgame.
- iknowstuff 4mo ago
  Seems cheaper (and so far more robust) to have an agent audit downloaded code
- Gigachad 4mo ago
  It's more likely we will move to a world where desktop OSs have a security model like ios/android so malicious software can't steal your data.
shevy-java 4mo ago
While this makes Arch Linux look bad right now, I recall how many years ago Gentoo was leading the pack with regards to having many clever people on board. Then came Arch Linux and eventually it put Gentoo as a second tier distribution. Arch has a lot of momentum; I myself am using Manjaro right now, primarily because it makes many things - including compiling from source - simple. As simple as Slackware, before Slackware fossilized (it's still alive of course, but just look at the most recent ISO release, then you'll understand the problem; when a distribution is no longer able to release .iso files, then it is in my book dead).
- BoingBoomTschak 4mo ago
  Arch has always been script kiddie tier compared to Gentoo lol.
sunshine-o 4mo ago
This is something that worries me with a distribution like Alpine Linux. It is hard to avoid a package like chromium [0] or firefox which are in the "community" repo. Now have fun check it at every update, this is not practically feasible. For the web browser one can say we should use Flatpak anyway but there are a lot of other apps like sway from the community repo that cannot be flatpaked. - [0] https://pkgs.alpinelinux.org/package/edge/community/x86_64/chromium https://pkgs.alpinelinux.org/package/edge/community/x86_64/c...
- Lyngbakr 4mo ago
  But the community repo in Alpine is vetted and reviewed unlike AUR, which is a wild west.
fooqux 4mo ago
For those worried, I found a repo with a collection of up-to-date scripts and package lists to help check for any infections: https://github.com/lenucksi/aur-malware-check https://github.com/lenucksi/aur-malware-check
- reedlaw 4mo ago
  I did the malware check using Claude, providing it with the same list (https://md.archlinux.org/s/SxbqukK6IA https://md.archlinux.org/s/SxbqukK6IA), and it did essentially the same things as this script does to verify. So either way should do the trick.
  - fooqux 4mo ago
    I think, for this, I'll trust something community verified and not the potential hallucinations of an AI. But we all put our trust in something I suppose. Glad you're clean.
    - reedlaw 4mo ago
      Good instinct. I did both. The script came out later.
    - Induane 4mo ago
      Malware has started sprinkling references to nuclear shit and other strings that trigger model safety so they'll refuse to actually scan them.
Simulacra 4mo ago
This is my fear with Linux and privacy - malware that leaks private data while using ie Tor, or other "anonymous" programs.
- roboslone 4mo ago
  How is it Linux-specific?
1vuio0pswjnm7 4mo ago
What perecentage of Arch users compile the kernel and userland software from source What Linux distribution^1 has the highest percentage of users who compile from source Is it Gentoo 1. Besides Linux from Scratch
- tmtvl 4mo ago
  I'd expect no more than a fraction of a percent of Arch users compile the kernel and userland from scratch. Gentoo may not have the highest percentage of users who compile from source because there's binary packages available now. Maybe Exherbo, Source Mage, or Lunar may have the highest percentage outside of LFS.
smetannik 4mo ago
I might be wrong, but this situation seems like a signal of desktop Linux adoption growth
aftbit 4mo ago
Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers. I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack. Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly. Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.
- TingPing 4mo ago
  There is no official tool to download aur repos, so that’s up to whatever you do.
  - aftbit 4mo ago
    I've used three in my career as an Arch user: yaourt yay paru https://github.com/Morganamilo/paru/issues/1563 https://github.com/Morganamilo/paru/issues/1563
- gavinhungry 4mo ago
  > I should be able to set a minimum package age just like I can with pnpm. I recently worked up a patch [1] for pakku [2], after being inspired by pnpm. [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku_add-MinAurAgeHours.patch https://github.com/gavinhungry/patches/blob/main/pakku/pakku... [2] https://github.com/zqqw/pakku https://github.com/zqqw/pakku
- whateverboat 4mo ago
  Better would be to namespace AUR packages. That way, ownership is not lost and we don't need orphaning at all.
  - no-name-here 4mo ago
    Are you suggesting like <package-name>.packaged-by.joe-Schmoe ? And then if Joe Schmoe abandons it, people should instead switch to <package-name>.packaged-by.Abe-Lincoln etc?
0x59 4mo ago
looks like I installed a package 3 weeks before it was comprised. I try to limit surface area as much as possible, and this package seemed to be required for a project I'm working on. (turns out it wasn't, but i didn't know that yet)
scarlehoff 4mo ago
I like the aur wrappers for the convenience, but if I've already limited my AUR consumption quite a bit, I think from now on all aur updates will be manual. One thing programs like yay could do though is to tie the packages to the maintainer. If the maintainer changes, it should be treated as a completely separate package. Not a perfect solution, but could avoid a few automatic upgrades.
- deleted 4mo ago
  [deleted]
beej71 4mo ago
There are 15k orphaned packages on AUR. I just adopted 3 rarely-updated ones this morning (sorting by most popular) and got them built. If you're using an orphaned package, consider adopting it so the baddies can't.
quertyrecord74 4mo ago
Where can i find the source diff that has the origins of the malware. Slashdot reported it has been delted. I would love to see the diff.
eviks 4mo ago
It will be under control when the underlying issue is fixed
deleted 4mo ago
[deleted]
jzer0cool 4mo ago
I understand this was AUR. AUR or not could someone share their steps installing any package? How to ensure package you are installing (and deps) are not malware? Because installed (bad package) seems difficult to really undo.
snvzz 4mo ago
It is safe to assume that at least one actual Arch developer was compromised by this. The followup attack on Arch itself is not going to be pretty.

319 points by qwertox 4mo ago

As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. `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. Keeping the amount of packages low, only use what you need, also makes this a whole lot simpler when it's time to upgrade.

dbgobrrr 4mo 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 4mo 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 4mo 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 4mo ago
    There's some big stuff in AUR like the binary VS Code and Chrome, fwiw.
    - newsoftheday 4mo 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 4mo 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 4mo 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.
- mcv 4mo 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 4mo ago
    How much work is created (and for who) when a package is moved to the official repository?
    - homebrewer 4mo 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 4mo 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 4mo ago
    How would this help against someone submitting an actual, non-compromised version bump, then adding malware once it's accepted?
cge 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
    This. Who needs social engineering NPM maintainers when there are thousands of freebie AUR ones.
- embedding-shape 4mo 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 4mo 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 4mo 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 4mo 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 4mo ago
    How is that relevant unless you read the make file?
    - embedding-shape 4mo ago
      If you don't trust upstream, a PKGBUILD from AUR is the least of your problem.
- kcyb 4mo 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 4mo ago
    I'd be surprised if you did it as a Debian user!
  - 4mo ago
-mlv 4mo 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 4mo 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 4mo 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 4mo 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 4mo 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 4mo 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_ 4mo 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 4mo 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 4mo 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 4mo ago
        > doing their due diligence (and more) Do you know how? This sounds like an unpractical high amount of time consuming task.
Gud 4mo 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]

tryauuum 4mo ago

How bad was it?

graemep 4mo ago
1,500 packages out of 107,000 so pretty bad, ameliorated by only affecting installs of those in a window of a few days. AUR comes with a warning that its up to you to check what you install from there.
- __s 4mo ago
  I was concerned at headline, then saw "oh just AUR" Next up, "millions of malicious packages still not taken down on internet"
- maxerickson 4mo ago
  I wonder what typical AUR usage looks like. I apparently have 27 packages installed and last updated one in November.
  - TomK32 4mo ago
    There's more than one way but this lists packages not installed by pacman itself: pacman -Qm Only 237 on my 12 year old system but I rarely update AUR packages and usually try to remove unused ones before updating.

anthonj 4mo ago

I cringed hard when some people started to make pacman wrappers that could install from AUR directly. I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.

mqus 4mo ago
This sounds like your update process is quite involved then. Or do you just not do it?
- anthonj 4mo ago
  I only have a couple of things in /opt/ and some manually installed fonts, and vim plugins in my home. Everything else that I don't use often lives in the original cloned git repo in /home/projects and never really gets installed. Of course the process breaks down for a large amount of packets, but I've never been in that situation. In part because the official repo is already large, and in part because I like minimalism. If that even became an issue, I would manage a personal set of pkgbuild probably.
Grombobulous 4mo ago
For me, this tradeoff isn’t worth it. I didn’t switch to Linux so that I can waste time going to websites and clicking “download” to update my programs like a Windows user. The pacman wrappers you mention are crazy, though.
- anthonj 4mo ago
  I get it, but you only need to do that for the odd cases of packages not present in the official repo (not that common at all for me at least). Also if the software is downloaded in the form of a git repo, you only needed to checkout the new tag and rebuild, don't need your browser at all.
  - 4mo ago

new_usemame 4mo ago

[flagged]

Havoc 4mo ago

As I undertood it this was mostly orphaned packages?

Shank 4mo ago
That's correct, orphaned packages could be adopted seemingly automatically, so someone did and then published malware in bulk.
- beej71 4mo ago
  This makes me want to adopt more packages. Lots of the orphans barely need updating.
gbin 4mo ago
Yes and honestly super kudos to paru's creator for the nagging warning about installed orphan packages that made me remove them immediately. So with a dozen of various systems running arch/cachyos for various purposes, 0 impact. We seriously dodged a bullet though, should we have some kind of AI spotting shady activity before it hits the userbase?
ajross 4mo ago
Not even "packages" in the distro sense. You can't use software installed with Arch to install this stuff via any path that isn't isomorphic to rebuilding the package yourself. This was the AUR repository, which is the community-maintained soup of non-distro packages. They're packaged using the same tools and technology, with the intent that they can be easily validated and promoted to core stuff in the future. But they aren't really "Arch Linux". You need to deliberately enable and install tools to pull stuff from it. Think of this as Steam or Chrome. You can install those on Arch, and people do, but if Chrome extensions or Steam games suffer an incident like this you don't blame the distro.
- cge 4mo ago
  > They're packaged using the same tools and technology, with the intent that they can be easily validated and promoted to core stuff in the future. That's perhaps the intent ideally, but in practice, it feels like AUR tends to be (a) niche, esoteric things that will never be anywhere outside of AUR, even if they could, or (b) installation methods for proprietary/otherwise non-open packages that can't be. The latter seems to a major popular use of AUR: sorting packages by popularity or votes comes up with lists that seem to be mostly these. And that's likely a significant draw for non-technical users. If you want to install things like Dropbox, Chrome, VS Code, Minecraft, Zoom, Slack... they all show up in AUR. By their nature (usually extracting packages from upstream installation methods), they tend to be more complicated than generic AUR packages. They are also often quite a bit more convenient than using the upstream packages, which might not interface well with Archlinux, might only be available with installation methods that clobber things, might be deb/rpm only, etc. I wonder if it would make sense to have a more trusted/vetted repository of these sorts of scripts, separate from core repositories but also not as free-for-all as AUR. That might go a long way toward keeping non-technical users from being drawn to AUR.

robby_w_g 4mo ago

I’ve made a point of not installing any AUR packages. It’s really tempting when there’s a package that’s not available via pacman, but at the end of the day I’d rather build from source myself or use a docker image.

anothermoron 4mo ago
Sadly they forced anybody with an older nvidia gpu to use some AUR package some months back.
popcornricecake 4mo ago
I've made a point of always installing software via the package manager. That means making my own PKGBUILDs if there's not already good ones available. I don't want to ever sidestep the package manager and go `sudo make install` or something. That feels like taking a shit in your system directories and you'll never be able to clean it all up after a short while.

bitmasher9 4mo ago

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

graemep 4mo ago
Arch is fine if you do not use AUR. If you use AUR check everything. Most distros are too. All the big distros have pretty good track records.
fooqux 4mo ago
The AUR is user supported and thus malware sneaks into packages all the time, although admittedly not to this scale. Still, it's pointedly not secure and has always had "here be dragons" signs plastered all around it.
- bitmasher9 4mo ago
  That’s not so much an example of who is using best practices, as it is an example of who is using worst practices.
halfcat 4mo ago
> Who is doing package management right these days? Who is doing it securely? QBASIC. When you need a package you type it in from a magazine. Virtually anything you could ever need is only 1-12 weeks away.
- vunderba 4mo ago
  QuickBasic, the commercial version of QBASIC, also supported BI files. These could be used to bundle shared code for things like high-precision timers, interrupt usage, etc.
anon7000 4mo ago
There are definitely LTS distros where the official packages are not updated ASAP. Npm lets package authors publish new versions to all users immediately. Anything that doesn’t allow that is better. Some distros only incorporate patch/security updates for example. AUR is worse, in that there may not be official authors and you can take over releases of a package. Like, you’ll have random users publishing the release for some application that doesn’t have their own Arch release. And if that user disappears, someone else may take it over

w4yai 4mo ago

"linux has no malware, windows bad boooh"

dist-epoch 4mo ago
"linux has a central package manager with every app that you need, so you don't need to install random apps from random websites like on windows"
- w4yai 4mo ago
  > central That will end badly at some point

rvz 4mo ago

Who's on Arch Linux btw?

mkayokay 4mo ago

So from a quick read, it seems it installed "atomic-lockfile", "js-digest" or "lockfile-js" from npm. A list of affected packages is here [1]. Didn't find any quick info on how to check a system, so I ran the following command to find foreign packages and some date related infos: > pacman -Qmi Check the output against the list of affected packages. Then, you can also grep for those files in various locations: > grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json" > grep -rl "atomic-lockfile" ~/.npm 2>/dev/null > grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null Don't know if the packages delete themself after they run. I just wanted to provide some basic commands, as all the other infos I found didn't provide any help. [1] https://md.archlinux.org/s/SxbqukK6IA https://md.archlinux.org/s/SxbqukK6IA

DavideNL 4mo ago
Also see: https://github.com/lenucksi/aur-malware-check https://github.com/lenucksi/aur-malware-check
jeroenhd 4mo ago
The attacker used at least three Node dependencies in the attack, just checking for atomic-lockfile is not enough. The names js-digest and lockfile-js were also used, and at some point the attacker switched to bun instead of npm.
stefan_ 4mo ago
I love that even when trying to put malware into Arch Linux AUR, the malware is still distributed through NPM. Legendary platform.
shlip 4mo ago
Here is how I did it : Get a list of installed packages originating from AUR using 'yay' : yay -Qam > packages_aur.last Get list from https://md.archlinux.org/s/SxbqukK6IA# https://md.archlinux.org/s/SxbqukK6IA# : curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt then : grep -wFf compromised.txt packages_aur.last should spit out the packages that are in both files, hence were compromised at some point, I guess.

landdate 4mo ago

> It was bad enough when finding out more than 400 AUR packages for Arch Linux users had been infected with malware but now that number has risen to around 900 a few hours ago and now in the end at more than 1,500 user-contributed packages.been infected with malware I never had a need for the AUR. If I want a package not in the official repository I build it myself or if it has a binary release I will download it. this way i don't have to use root when building and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases. At least in this way there is one less level of possible malicious code insertion in developer -> user, vs develeper -> maintainer -> user.

well_ackshually 4mo ago
[flagged]
NekkoDroid 4mo ago
> this way i don't have to use root when building `makepkg` will actively refuse to run if you are invoking it as root (unless you specifically invoke it with something like `env EUID=123 makepkg ...`). > and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases. I do wish pacman would support a user level installations. It will refuse to install packages as non-root (which you can go around by using user namespaces and mapping yourself to root).
- landdate 4mo ago
  Maybe I used imprecise wording. Not root, but must be part of sudoers. Or am I misunderstanding how the process works? Don'tWhenever I have installed a package from aur with yay it requires user being part of sudoers.
  - NekkoDroid 4mo ago
    Yea, but that is to install the package after it was built (or installing dependencies). The build itself is done unprivileged.

28304283409234 4mo ago

Could we be heading towards a world where it's just more secure to write inhouse software again, only now with AI agents? Not closed source per se, but 'own source'?

dontfeedthemac 4mo ago
this
jl6 4mo ago
The endgame is to generate a binary image for an entire single-purpose OS/unikernel that does exactly and only what you require of it. No source to open or close.
- ianburrell 4mo ago
  The build process is just as vulnerable.
  - jl6 4mo ago
    Sounds more midgame.
iknowstuff 4mo ago
Seems cheaper (and so far more robust) to have an agent audit downloaded code
Gigachad 4mo ago
It's more likely we will move to a world where desktop OSs have a security model like ios/android so malicious software can't steal your data.

shevy-java 4mo ago

While this makes Arch Linux look bad right now, I recall how many years ago Gentoo was leading the pack with regards to having many clever people on board. Then came Arch Linux and eventually it put Gentoo as a second tier distribution. Arch has a lot of momentum; I myself am using Manjaro right now, primarily because it makes many things - including compiling from source - simple. As simple as Slackware, before Slackware fossilized (it's still alive of course, but just look at the most recent ISO release, then you'll understand the problem; when a distribution is no longer able to release .iso files, then it is in my book dead).

BoingBoomTschak 4mo ago
Arch has always been script kiddie tier compared to Gentoo lol.

sunshine-o 4mo ago

This is something that worries me with a distribution like Alpine Linux. It is hard to avoid a package like chromium [0] or firefox which are in the "community" repo. Now have fun check it at every update, this is not practically feasible. For the web browser one can say we should use Flatpak anyway but there are a lot of other apps like sway from the community repo that cannot be flatpaked. - [0] https://pkgs.alpinelinux.org/package/edge/community/x86_64/chromium https://pkgs.alpinelinux.org/package/edge/community/x86_64/c...

Lyngbakr 4mo ago
But the community repo in Alpine is vetted and reviewed unlike AUR, which is a wild west.

fooqux 4mo ago

For those worried, I found a repo with a collection of up-to-date scripts and package lists to help check for any infections: https://github.com/lenucksi/aur-malware-check https://github.com/lenucksi/aur-malware-check

reedlaw 4mo ago
I did the malware check using Claude, providing it with the same list (https://md.archlinux.org/s/SxbqukK6IA https://md.archlinux.org/s/SxbqukK6IA), and it did essentially the same things as this script does to verify. So either way should do the trick.
- fooqux 4mo ago
  I think, for this, I'll trust something community verified and not the potential hallucinations of an AI. But we all put our trust in something I suppose. Glad you're clean.
  - reedlaw 4mo ago
    Good instinct. I did both. The script came out later.
  - Induane 4mo ago
    Malware has started sprinkling references to nuclear shit and other strings that trigger model safety so they'll refuse to actually scan them.

Simulacra 4mo ago

This is my fear with Linux and privacy - malware that leaks private data while using ie Tor, or other "anonymous" programs.

roboslone 4mo ago
How is it Linux-specific?

1vuio0pswjnm7 4mo ago

What perecentage of Arch users compile the kernel and userland software from source What Linux distribution^1 has the highest percentage of users who compile from source Is it Gentoo 1. Besides Linux from Scratch

tmtvl 4mo ago
I'd expect no more than a fraction of a percent of Arch users compile the kernel and userland from scratch. Gentoo may not have the highest percentage of users who compile from source because there's binary packages available now. Maybe Exherbo, Source Mage, or Lunar may have the highest percentage outside of LFS.

smetannik 4mo ago

I might be wrong, but this situation seems like a signal of desktop Linux adoption growth

aftbit 4mo ago

Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers. I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack. Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly. Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.

TingPing 4mo ago
There is no official tool to download aur repos, so that’s up to whatever you do.
- aftbit 4mo ago
  I've used three in my career as an Arch user: yaourt yay paru https://github.com/Morganamilo/paru/issues/1563 https://github.com/Morganamilo/paru/issues/1563
gavinhungry 4mo ago
> I should be able to set a minimum package age just like I can with pnpm. I recently worked up a patch [1] for pakku [2], after being inspired by pnpm. [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku_add-MinAurAgeHours.patch https://github.com/gavinhungry/patches/blob/main/pakku/pakku... [2] https://github.com/zqqw/pakku https://github.com/zqqw/pakku
whateverboat 4mo ago
Better would be to namespace AUR packages. That way, ownership is not lost and we don't need orphaning at all.
- no-name-here 4mo ago
  Are you suggesting like <package-name>.packaged-by.joe-Schmoe ? And then if Joe Schmoe abandons it, people should instead switch to <package-name>.packaged-by.Abe-Lincoln etc?

0x59 4mo ago

looks like I installed a package 3 weeks before it was comprised. I try to limit surface area as much as possible, and this package seemed to be required for a project I'm working on. (turns out it wasn't, but i didn't know that yet)

scarlehoff 4mo ago

I like the aur wrappers for the convenience, but if I've already limited my AUR consumption quite a bit, I think from now on all aur updates will be manual. One thing programs like yay could do though is to tie the packages to the maintainer. If the maintainer changes, it should be treated as a completely separate package. Not a perfect solution, but could avoid a few automatic upgrades.

deleted 4mo ago
[deleted]

beej71 4mo ago

There are 15k orphaned packages on AUR. I just adopted 3 rarely-updated ones this morning (sorting by most popular) and got them built. If you're using an orphaned package, consider adopting it so the baddies can't.

quertyrecord74 4mo ago

Where can i find the source diff that has the origins of the malware. Slashdot reported it has been delted. I would love to see the diff.

eviks 4mo ago

It will be under control when the underlying issue is fixed

deleted 4mo ago

[deleted]

jzer0cool 4mo ago

I understand this was AUR. AUR or not could someone share their steps installing any package? How to ensure package you are installing (and deps) are not malware? Because installed (bad package) seems difficult to really undo.

snvzz 4mo ago

It is safe to assume that at least one actual Arch developer was compromised by this. The followup attack on Arch itself is not going to be pretty.