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.
`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious.
(It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)
Git repo have been attacked other times in the past, but a 500/1000 stars project still sounds more trustworthy than a user repository managed by randos with a couple of upvotes.
I still use the aur for simple cases, but when I see aur packages depending on multiple other aur packages I immediately leave.
I'd recommend that you do – it's not very taxing, and if you only have a few then you won't even be doing it much. I'm not auditing the program code itself (where even available), literally just checking that the AUR package actually installs what it says it does/I expected.
It shows the overall diff since last update, not patch-wise. But it does show any extra patch file, install script, etc. – not just the PKGBUILD – if that's what you meant.
People continue to criticize Arch for being elitist or gate-keeping to keep casuals out but there are clear benefits by not allowing dangerous things to be simple. This is true in many aspects of life.
After using Void Linux I switched to `aurutils` to get a similar separation on Arch. I can easily maintain a local AUR repo by compiling/making my own binaries and can use `pacman` to install and manage them which improves the upgrade process overall.
> People continue to criticize Arch for being elitist or gate-keeping
I have the complete opposite experience. Arch makes it easy to get in and get hacking right away. Their beginner guide's on the wiki were a gem 10-15 years ago... made it super easy to get up and running. I don't have the time these days to tinker - but boy do I love some Arch.
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.
You then get the advantage of the OS’s package manager accounting for everything, however. It’s quite nice to not wonder whether there’s random stateful detritus throughout your system and what it might be affecting. (OK, to be honest there still will be, but much less of it, and a greater part of it will be attributable.)
I think it's also a bit of a testing ground for the main repos as well. I maintained the `ruby-build` AUR package for a couple of years after the previous maintainer wanted to step down, but they eventually added it to the main repos and now it's maintained by one of the official people. (I don't recall ever having to do more than paste in the new release tag into the PKGBUILD each time and then generate the new .SRCINFO and checksums in terms of actual maintenance, although I'd test locally first before pushing of course).
I only saw automation around this for the first time earlier this year when noticing that a package was multiple versions out of date and tracking it down to a bot (in the pre-LLM sense) on Gitlab for the package that gave a false negative on a version update due to the format of the upstream git tags changing (either they added a `v` to the beginning or removed it, I forget which). My takeaway from that experience is that while automation can be nice, I'm not convinced that the benefits outweigh the potential for bugs like that if it relies on invariants like git tags that are realistically not something that all upstream maintainers are going to be pedantic about keeping standardized.
I understand that having a relatively small number of people maintaining a large number of packages makes it burdensome to manually update everything, but on the other hand, nobody asked me before promoting the AUR package I maintained to the main repos, and I would have been happy to keep doing it indefinitely! I'm not a "official trusted contributor" by any means, but I also know that I would have kept doing what I already did for years in exactly the same way without any issues, so I can't help but feel a bit like like a known good with hypothetical risks was thrown away for something that will produce at best the same results with less severe but more concrete risks. I wish I had a solution for not getting stuck at that local optimum, but incidents like the one in the article will only make it more of an uphill battle.
(edit: to clarify, I'm not proposing that the package should have been left in the AUR, but that I wish there were a way for them to have just let me keep maintaining it as an "official" package. Maybe something like the kernel model where someone trusted could vet the PKGBUILD updates I do and decide whether to merge them or not rather than doing the same but with a bot, and then maybe not noticing that the bot is silently failing...)
AUR and similar repos for other distros scare the hell out of me.
Tutorials using them are so widespread… Start feeling like a weirdo for not wanting to give an unknown rando full indefinite root access to the system, with virtually zero peer review… all to install one version of a package where updates are undesired or infrequent…
You don't have to. The AUR is just a bunch of PKGBUILD text files, which if you don't feel competent enough to read and understand and trust, you can create your own local versions of and install from. It's just a recipe file that says download a program from this github URL, make sure the hash matches and then extract it and move the files to system directories.
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.
Wrapper is really helpful for every time you do pacman update for official repo, you should recompile all of the AUR repo as well, otherwise you'll be in the land of 'partial upgrades'. Some packages don't complaint too much, while others do
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.
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?
> 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.
Why not? I agree some limits should be added, but also shouldn't be too limited, then lots of things that could be properly maintained, won't. Maybe limit adoption to one package a month or something, to users registered since some date. But no one has automatic (& unreviewed) updates applied to their locally installed AUR packages (that'd be utterly bananas) so the attack vector is already pretty small here.
> 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.
No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-where-it-is-uploaded on GitHub. The code itself is dynamically renamed in its methods, re-used shuffled offsets for encrypted symbols, among other things. It's a mutating malware and the worst enemy from tools that rely on signatures.
Ironically, APT28/29 is somewhat relying on Microsoft being too slow to auto block users and repositories on GitHub that are the C2 infrastructure. Think about that for a second what this implies for your cyber strategy.
By the time you're able to scan signatures or "strings" you're already playing a cat and mouse game with a fully automated botnet, which you will never win. The only other ones I've observed during the last week that seem to be able to track this malware implant's changes were socket.dev. ALL other supply chain tools didn't even know about Miasma and re-invented it as a new campaign. They didn't have the skilled enough people nor toolchain to reverse the malware payload quickly enough to be able to keep up every 24h when they push out a new adapter for another ecosystem.
By fully automated I mean they're already using the credentials they stole less than 48 hours ago from a different package ecosystem, because the email addresses and names etc keep appearing from people who likely didn't even understand the impact of this self-spreading worm.
And having an IOC that checks for, let's say, any package that depends on bun won't help either because the malware will just use external means to re-download it. See the second PyPi campaign, where they just changed the dropper to use compressed WHL files and the setup.pth files that are auto-executed to download the dropper. They changed this after the PyPi maintainers flagged the first wave of malware droppers from the RedHat campaign.
As long as the package managers in those ecosystems aren't fully rewritten from scratch to accomodate for chroots, sandboxes, network and domain logs that are _only allowlistable per entry_ this won't change, and will stay being a feasible malware deployment strategy for supply chain attacks.
Repo for Mitigation Tool (I'm human so I play catch 21 with an LLM powered botnet) [1] ... Tech details in the blog post [2]
Also this is a problem across all package managers. Composer is also affected. Rubygems is also affected. NPM is also affected. PyPi is also affected. Go is also affected.
Nobody is talking about this, and I think this should be more openly discussed how much negligence and external trust we put in package managers in general. This really needs to change.
With this _actual_ attack, it would have been trivial to detect. The signature was:
1. Orphaned package adopted
2. Has post-install hook added
3. Which uses npm or bun
Yes, you're right - detecting this could have led to a more sophisticated attack. Security is always a cat and mouse game. The purpose isn't to stop every attack - it's to raise the costs for attackers and the visibility for defenders.
Any attacker who wants to attack 1000s of packages is going to necessarily leave some signatures, unless they're extremely careful. If they change one thing but not another, you can tie them both together.
Think of this like email anti-spam. It hasn't gotten rid of spam, but it has made it much more expensive to operate.
Combine this with a minimum package age to give the scanners time to run and humans time to inspect, and the ecosystem as a whole gets much more secure.
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.
Have you checked the install date? I'm not sure which are the compromised version numbers, but if they were installed before June 10 you're probably safe. (I think libgdata 0.18.1-5 used to be on the main repos in February, and has recently been downgraded to AUR, so you may be fine).
Only packages from AUR have been compromised, meaning a normal update `pacman -Syu` won't install them, they'll only be installed by `makepkg` or AUR helpers (such as `paru`, which asks you to review the PKGBUILD diff).
Also, if you had installed a compromised version, uninstalling the packages is not enough, you'd probably need to reinstall your system and rotate all credentials. More info here and on the linked blog: https://discourse.ifin.network/t/400-aur-packages-compromise...
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.
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.
"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
This is like saying a user who clone a random git repo is not to blame and git-scm should do more to prevent cloning of malicious repos.
If it is not official, it is your job to review, if you dont like it, use iOS instead of Arch Linux.
If you crash your car, you are liable for the accident. If you aren't ready for that, take the bus.
> If you crash your car, you are liable for the accident.
Because I didn’t go through all the blueprints and find the flaw that led to the crash. This is a dumb
argument. It’s also the one the AUR appears to be making.
No, it's completely valid. The arch home page warns you that you're the one responsible for your system, and get to keep both pieces when something breaks. Everything is assembled with this philosophy in mind. This message is reinforced ten times more before the system is even installed and is up and running.
If this is not for you, that's fine, but it's been working very well for some of us for... decades, at this point? I'm not amused by the amount of people here wanting to turn arch into another Ubuntu, most of them having zero familiarity with how the AUR works, or arch more generally.
>but it's been working very well for some of us for... decades, at this point?
but it's worth asking why it's been working well. Has it been working well simply because it's been a niche ecosystem, or even because you wouldn't have known if it didn't because nobody did security audits?
The Arch distribution model, which operates like the Javascript ecosystem, as in having a barebones core and then a zoo of unregulated third party community packages does not seem fine these days. As it became more popular it has naturally drawn attention and from that moment on you're just screwed because you have no security infrastructure. Arch pretty much lived off security through obscurity.
And in particular with the popularity of these spin offs, I forgot what the name of the tiling wm thing is that got very popular, I think a lot of users are not aware that they're doing the software equivalent of buying medicine off craigslist
> The Arch distribution model, which operates like the Javascript ecosystem, as in having a barebones core and then a zoo of unregulated third party community packages does not seem fine these days
It's hard to take the rest of your comment seriously when you don't seem to have a basic understanding of the parts involved here. Arch's distribution model isn't at all like npm (which I guess is what you're actually talking about here), but the AUR specifically is pretty similar to npm. But the AUR isn't Arch's main distribution model, and the official Arch repositories contain a ton of packages in the core, so not even the "barebones core" is correct here.
Arch has pretty much lived off the experience of its users, which is the entire purpose and value-proposition of the OS. You want someone else to be responsible, you're welcome to use the countless of other distributions, Arch is quite literally not the OS for a "Don't read anything and press Update, hope for the best" experience, and I hope the core team continues to push back against that, which they've done for decades at this point.
It's sad, because overall you have a point somewhere there but the big misconceptions kind of hide that message though.
>But the AUR isn't Arch's main distribution model, and the official Arch repositories contain a ton of packages in the core, so not even the "barebones core" is correct here.
I don't think that narrative is supported by the numbers. Arch's repositories are about a magnitude smaller than either the AUR or "batteries included" distributions like Debian. (about 10k to 100k packages), there are more people using Arch derivatives than arch, and according to some community polls, granted I can't verify their methodology, something north of 90% of arch users use the AUR.
If you look at the most popular packages in the AUR, it's the most popular web browsers, virtually every VPN client, popular professional software like davinci, incredibly popular messaging clients, Spotify, Zoom, billion+ userbase software and the vast majority of password managers.
And if you look at who maintains those, it isn't the company, in many cases it's a random pseudonymous user who doesn't show up on Google. And I don't get this strange aggressive tone of suggesting I use something else. I do already, because as should be obvious I think that's a bonkers security model, but it deserves to be pointed out.
I do not think that the majority of people running arch today in practice realizes that their password manager they installed from that repo everyone uses is managed by an absolutely random person on the internet.
> I don't think that narrative is supported by the numbers
Why are you looking at numbers? Arch Linux's official way of distributing software to it's users are the repositories called "core", "extra" and "multilib", anything else than those are "unofficial" and user's responsibility to how they handle it. No need to look at any numbers, literally go to Arch Linux's website and read how it works if you don't know since before.
> there are more people using Arch derivatives than arch
May be, find it hard to believe that's true outside of gaming, but regardless, that doesn't mean suddenly the AUR becomes safe. And if the complaint is about how these Arch-derivitives educate their users, go to their message boards and share this, that has little to do with Arch Linux itself, literally why there are multiple distributions in the first place.
> something north of 90% of arch users use the AUR.
Yes, like me, and probably every other Arch Linux user. I'm sure every developer on macOS at one time uses the terminal, does that mean "rm -rf" suddenly needs to go away?
> it's a random pseudonymous user who doesn't show up on Google
So what, why it matters? All that matters is that the package does what you expect, and use official sources if that's the point. My password manager's AUR package is built by someone I don't even recall the username of, is this a problem in practice? No, because I do what my OS tells me and reviews random 3rd party software I download from the internet. Every time I upgrade, I see that the only thing changing is the URL which points to the official domain, and a content-hash, that's it. The user could be a pirate in Somalia for all I care.
> I do not think that the majority of people running arch today in practice realizes that their password manager they installed from that repo everyone uses is managed by an absolutely random person on the internet.
I think if you look at a certain sub-section of users who install and do things without thinking, you're absolutely correct. But I don't think the rest of the user base who uses Arch for the very value proposition it offers, should suffer because there is a small sub-section of users who install OSes based on what influencers are pushing to their viewers today.
They *are* doing the basic housekeeping. What do you think this announcement is, if not exactly that? AUR is very clearly documented as user-submitted, and automatic installs from it are heavily discouraged by the maintainers for this reason. Malware aside, there is very little quality control, and a poorly made AUR has the potential to break the system pretty badly. (Though, in my experience, most of the useful AUR packages are trivial to remove if something goes wrong.)
The officially maintained repositories (which are part of a default installation) were not affected. Users need to go somewhat out of their way to use an AUR.
The definition files are all plain text and not especially complicated. It's not too difficult to glance at the file before doing an install to get a basic idea of what it's about to do, just like you should do when running a random shell script or cloning a random git repo. Indeed, most AURs are implemented by cloning an upstream git repo and configuring it so it can be built. The same basic threat model applies: Do you trust the install script? Do you trust the upstream URL whose code it is about to compile?
i read all the pkgbuild diffs, still doesn't give me a good sense. sure, i can verify that it's coming from the official repo but even then there's no guarantee that there isn't junk in there or that the git ref is actually pointing at the right thing.
it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.
> it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.
Ok, so instead of having a reasonable security posture yourself, you'd rather rely on a number of random strangers who've eyeballed the PKGBUILD instead?
Generally, I think Arch tries to prevent users from relying on bad signals, and this principle might be applied here too.
> i read all the pkgbuild diffs, still doesn't give me a good sense. sure,
Do you have an example of a diff that doesn't give a good sense? I review all my diffs too, but I feel like all of them give me a good sense if it's safe to install or not. I mean, why would I otherwise, what's the point in reviewing if you don't use it to make a decision if to install it or not?
pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or linked patch or late download dependency in the package itself).
> the diffs only really show that it's coming from the same source
What else do you have to review? Both in the cases of binaries and source, the idea is that you trust upstream already, otherwise you shouldn't install software from them. And since you trust upstream, the only thing you need to review in the PKGBUILD is quite literally: Where is this stuff coming from, is it the official domain/repository? Are there other non-official dependencies? Are there patches applied?
Once you've reviewed those, you're done, and as safe as if you installed straight from upstream, zero false sense of security here.
You're mixing concerns here, as what you describe is completely different issue.
blindly trusting upstream is not really a reasonable posture. that is pretty much the source of all software supply chain attacks.
there is work involved in figuring out how to get the complete diff of the code and dependencies that are included in the change, plus review time. this could range anywhere from 5-10m to 1h per package updated- if not more.
Well ArchLinux has a product for you if you want packages that were vetted: the official repositories.
AUR is just a centralized place to put user created packages, like npm is a place to put user created node packages.
Nothing is "disguised" here. Arch Linux makes an enormous effort to warn that due dilligence is required before installing things, and to dissuade users from using the User Repository at all, to the point of not offering package manager support for it. The wiki even cites previous instances where malware was discovered in the AUR packages.
The only way you could possibly not be aware of the AUR's nature as an "uncontrolled free-for-all" is if you didn't read the Arch Wiki, and anyone who doesn't read the Arch Wiki should not be using Arch Linux to begin with.
"Uncontrolled free-for-all" is exactly the status quo of programming language package managers such as npm and pip. It's just as easy for total randoms to sign up for an account and push packages on those services as it is to push a package to the AUR. Only the AUR made the lack of trust explicit and part of the culture.
PKGBUILDs are not packages. They’re (user-contributed) instructions on how to build packages.
> available through the OS's repos.
No. The AUR is a platform, similarly to NPM or PyPI, that allows users to upload PKGBUILDs. It is not part of “the OS’s repos,” and it says that loud and clear, multiple times, including on the front page.
You seem to have a wild misconception of what the AUR actually is.
It'd be more like a public toilet anyone could urinate in, and you lick the floor right next to the toilet and then is surprised that it tastes like pee. Of course there is pee on the floor, anyone can pee there!
Better analogy would blaming a supermarket that hosts an outdoor farmers market because you contracted food poisoning from a stand owned by someone else - NOT for buying food from within the supermarket itself.
Meanwhile one of the other customers has norovirus and is deliberately touching everything so others contract it.
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.
Yeah, I've prevented this locally too by never building such a platform in the first place, always the best solution!
Jokes aside and just in case, you do realize ports and AUR have two very different models? Ports is more similar to the official Arch repositories, which obviously doesn't suffer from the same problem, and AFAIK, there is no BSD-equivalent of AUR.
BSD is cool and useful for lots of reasons, but comparisons based on misunderstandings helps no one :)
There is pkgsrc-wip which is similar but run by one person who does at least some checking up on new users. AUR is just gigantic in comparison; pkgsrc-wip has about as many total packages as AUR has updated in the past week.
But why check the user instead of the actual code? That's like asking people to checking the GitHub user before they install a program from GitHub, instead of the program itself! Ultimately, the PKGBUILD is the only thing that matters here, not the author or how many others reviewed it.
That isn't what I ment, I should have said that the person who runs pkgsrc-wip helps submitters get the package correct (which can be more challenging than PKGBUILD since it is a more strict system and unless it is a Linux only package is more likely to need patches). Thinking about it more it isn't really the same as AUR since as I understand it packages without issues are likely to get into pkgsrc proper in most cases so it is mostly WIP as the name suggests (although not entirely as I recall, at least last time I used it). So you might be correct that there isn't really anything similar in the BSD world.
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.
You find one that builds from source, or you still review PKGBUILD and friends and lean more on evaluating the reputation of upstream and its maintainers, or you simply decide never to install binary packages. Your policy is yours to decide.
> Putting this on users is not a tenable solution.
The alternative would be to not have an AUR. Archlinux has official package repos where packages are vetted. The AUR (Arch User Repository) is not that. The AUR is there to provide greater variety of software than the official repos can, and it does that by not incurring the cost of being individually maintained by volunteer Arch staff and developers. It needs to not incur that cost for it to exist, otherwise it'd just be the official repos. It's like github, but limited to repos with PKGBUILDs.
And in this alternative past/future, everyone is using GitHub to host their PKGBUILDs instead, then someone gets tired/lazy and builds one repository that indexes those, and we have ArchPacBrewRepository or something, and very same issue appears again, unless people change their approach to installing random 3rd party software.
Ask an LLM to assess the package and do a web search for you. Nobody is installing tens of packages a day, you can take a few minutes to consider what you are installing. This isn't blaming the user, it's basic digital hygiene.
Lets take two real and random examples, and I'll share what I'd look for:
First, very easy one, we want to install Brave, so we find https://aur.archlinux.org/packages/brave-bin. All the dependencies are in the official repos already, so those we trust already, you open the downloaded PKGBUILD and you find it's downloading a binary from github.com/brave, you check to see it's the official GitHub profile/organization that you expect. Quickly scan prepare/package for anything out of place, like downloading more files not defined in "source" or whatever. In this case, "suid sandbox" stuff should make you investigate closer so you understand what that stuff does, many things related to Chrome has things like that. That AUR package also has a brave-bin.sh, so a look through that would make sense. AFAIK, everything checks out, this is literally just downloading the official release from GitHub, and extracts it into the right place, so if you trust the GitHub org/user, you can trust the PKGBUILD. The PKGBUILD also seems to be officially maintained by Brave themselves, so probably already there you can verify the AUR user and be done if you feel lax.
Second example is unofficial package, https://aur.archlinux.org/packages/lmstudio-bin, maintained by noureddinex and created by MadGoat, neither which seem official at a glance. Read through the comments to see if anyone else flagged anything, seems fine so again go read the source of the package and the PKGBUILD. PKGBUILD seems standard, downloads something from "installers.lmstudio.ai" so first thing to check is if that's actually the official website, so use search engine to find official website, copy the URL of the download, verify it's the same. In this case, lmstudio.ai is the real website, but download URL on website ends up being "https://lmstudio.ai/download/latest/linux/x64" in the HTML/DOM, so use "curl -v -L $URL" to see redirects, and then we've confirmed installers.lmstudio.ai is actually what they use for official releases. Read through "prepare" and "package", both seem standard and fine, then look through the rest of the files, all of them seem fine, mostly maintenance scripts for the AUR package itself. Package seems fine as a whole, and we could install it, if we're willing to review it again on upgrades in the future.
This is basically all you have to do. Writing what I did while doing it, made each "review" take maybe 5-10 minutes, and it isn't harder than that, regardless who the user is. You just need to know what to look for, and think how you'd "officially" install it anyways. And if what the PKGBUILD differs from what you'd imagine an "official install" would do, investigate if it makes sense and if not, don't install the package, maybe leave a comment for others in AUR to dive deeper.
Question is if this would be thorough enough for this attack? A package with a slightly more involved build process, maybe some patches because it was made to build on a different distro. Maybe you've already installed (and thoroughly inspected) it before, so you're only updating to a newer version, so you're not as thorough with your review. Or an xz-style backdoor.
Yes, it'd be enough. If a package you're using suddenly adds new 3rd party dependencies, you confirm this is actually needed, and if not, you know something is up. When you install software from random strangers, you have to be vigilant and consider the implications of what you do.
I recall the same situation recently with yt-dlp, as they started to depend on a JS engine for some captcha stuff or related. So when you see that, you need to adjust the mindset of "ah whatever it's probably fine" to "Ok, why are these changes actually here?", and if it's not worth reviewing, you might want to reconsider the approach of installing random binaries from the internet that are flagged as unreviewed.
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?
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.
If I understand, the malware is installed via npm from some subshell. But yeah I totally believe you have a detailed review of every package-lock.json and etc.
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.
That would be the same problem for official packages. Unless I am mistaken, the difference between maintainers for the official repos versus AUR, is that the former is a trusted/vetted person. But afaik, they also just package upstream software. I doubt they will read through tons of commits to see if there might be anything nefarious there.
It would be better if software would be forced to have something like a very advanced manifest file, with requested permissions. Malware has to eventually communicate with endpoints, so a declared whitelist of endpoints should definitely be part of such a manifest. Some wrapper program could set up a namespaces that allows just what is requested. Any software that requires `endpoints = [.*]` would make it obvious to the user that it is a really dangerous piece of software. Your code editor should not ship like that.
The first thing I can think of in this direction is flatpak, but that is really coarse grained, with defaults that are very lax. Also flatpak-like solutions do not expose an api to the wrapped application, which is both a pro and a con (a con when you consider installing application plugins requiring further permissions).
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.
> 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?
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.)
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.
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.
Stupidly low friction. Consistently failing to learn from the mistakes of package managers is bad enough. Failing to learn from your own is another level.
“Learning from your mistakes is good. Learning from the mistakes of others is better”.
For all its flaws, at least Cargo attempts to do that. AUR does not. No other package manager this regularly has hijacking problems.
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.
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.
> 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.
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 :)
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.
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.
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.
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).
> 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 | 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.
GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks.
GitHub also actually protects against repojacking and tombstones username/reponame combinations (that exceed a certain minimum popularity) and never lets anyone ever use them again.
The utility of AUR is also really based around being able to reuse the same repo without having to re-vet every single time. This kind of attack, that forces you to re-vet on every single upgrade so that trust inherently can't be established, is also not GitHub's model at all.
And go has a software package manager that heavily uses GH for distribution, and is arguably more VCS decentralized, but isn't vulnerable to this kind of attack, because it inherts GH's threat model, and doesn't implement the kind of choices that AUR decided to deliberately build into their system.
> GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks.
Changing your username would let anyone reuse the old username for whatever they want. Probably still today there are bots squatting any renamed accounts. Also, you bet Microsoft would hand over your GitHub username if it was reported by someone who holds a registered trademark in the US over that username, regardless of impact.
> The utility of AUR is also really based around being able to reuse the same repo without having to re-vet every single time.
I don't think they promise that anywhere, nor should you have that expectation. That would be like since you got legit copy from random-website.com/bin.exe today, you'd get that tomorrow too, clearly not true unless you know the owner of the domain or otherwise trust it.
> go has a software package manager that heavily uses GH for distribution, and is arguably more VCS decentralized, but isn't vulnerable to this kind of attack
Unless Golang suddenly have peer-reviewed packages, Golang has exactly the same problem as AUR in that anyone can create packages, and it's up to users to decide what to trust or not. Fair that the whole "orphaned packages" thing doesn't exists in Golang, but I think Arch probably favors stability more than people expect/think, that's why people can continue to maintain packages even though original maintainer disappears. Ultimately it's a trade-off, I don't think there is some absolute truth what is correct or incorrect.
Regardless of who maintains the package, if you use AUR as intended, it seems you'll avoid most security issues. It's when your expectations aren't aligned with what AUR actually promise, that people start getting hacked.
I don't know how it works these days, but a few years ago GitHub was happy to give away usernames from users who haven't touched their accounts in a long time to anyone who asked. Several people I know got vanity usernames that way. All you had (have?) to do is drop an email to GitHub's support.
Only thing I can find on requesting to take over an inactive account is here:
> We do not accept requests to release, transfer, or reclaim usernames on the basis that they appear inactive or unused. If the username you want has already been claimed, you will need to select a different available name unless you are submitting a trademark complaint as described below.
Also even the original user renames or deletes their account any popular repos they have will get tombstoned, so the new owner can't recreate them:
> GitHub uses a tombstoning algorithm to reduce the risk of repo-jacking by permanently retiring specific owner name, repository name combinations. The github/cmark-gfm example above is purely hypothetical, because, in that scenario, the old name would get automatically tombstoned. For example, even if an attacker managed to register the username github, they would still be prevented from creating a new repository with the name cmark-gfm because that owner name, repository name combination (github/cmark-gfm) would be permanently retired. Therefore, repo-jacking is only a risk for repositories that fall below a certain usage threshold. We don’t tombstone all renamed repositories because there’s a tradeoff between usability and security: a tombstone is a potential inconvenience for our users which we don’t want to impose unless there’s a genuine security-related reason to do so. That’s why our tombstoning policy only kicks in after the repository has met certain criteria, such as exceeding a specific number of clones.
Before that it was possible to contact support to reclaim any username provided that they had no meaningful public repos and they were inactive for a long time. It was at the staff's discretion, there wasn't an elaborate policy of what constitutes inactive, but I've successfully reclaimed a username inactive for 2 years myself.
The old policy was:
GitHub account names are provided on a first-come, first-served basis, and are intended for immediate and active use. Account names may not be inactively held for future use. GitHub account name squatting is prohibited. Inactive accounts may be renamed or removed by GitHub staff at their discretion. Keep in mind that not all activity on GitHub is publicly visible. Staff will not remove or rename any active account.
Attempts to sell, buy, or solicit other forms of payment in exchange for account names are prohibited and may result in permanent account suspension.
Meanwhile sometime around there I changed my GitHub username, and not reading up on the suggested process before doing so. The idea was to rename my account, then create a new account with the previous username, so no one else could squat it, as it's my firstname + lastname and the combination seems unique in the world, so it's basically just me. But a few seconds after renaming the account, it got squatted and even requesting to GitHub to reclaim it somehow, has fallen on deaf ears.
Lesson learned, create new accounts and never rename usernames, regardless of what rules the platform might share publicly.
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.
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?
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.
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.
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.
Yeah, the AUR is basically build scripts for github repos or a link to someones pre-built binary. It suffers from all the same problems that the underlying infrastructure suffers from. You could very easily argue that since github/npm/cargo/<your package manager of choice> has a supply chain issue so does the AUR.
>`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.
Not all tools are made for inexperienced people. Not everything is idiot proof. This is OK!
In my experience using the AUR:
1. when you first install the package you can read the build script (and you should). These are in a very standard structure, and if the one you are reading is weird and complicated consider not installing it. No one is forcing you to. Almost every build script I read just downloads a build from a tagged github release.
2. when you get an upgrade you are shown the diff. For almost every AUR package I use this is literally just changing the $VERSION variable and the subsequent $HASH of the download. It is trivial to see if anything (in the AUR script) is happening that is sneaky.
It's really not that scary. And if it's considered scary, there are literally dozens of other linux distros (not to mention Windows or MacOS) you could be using instead.
I'm not asking for myself. Yes, I understand the build process, and know what to check. I've also written PKGBUILDs before and have had packages in AUR. I'm sure you understand it too, as well as many people here.
But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
And, again, this attack was a relatively obvious one. Other attacks could be made much harder to notice.
Worse, distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves. Unlike ArchLinux, those sometimes do seem to promote AUR-helpers. In some cases, those distributions are apparently including AUR-sourced packages in their actual repositories.
Questions about these topics often result in typical Archlinux hostility. And in some sense, that's understandable: there are other distributions that most users should be using, and the frustration of people using Archlinux who shouldn't be is wearing. It is nice to have a distribution that offers the flexibility and space for experimentation that Archlinux does. It's one of the reasons I use it on some of my machines, while at the same time recommending against most others using it.
To some extent, this is just a wide cultural difficulty with Linux, and there isn't a clear answer. On one hand, you want enough gatekeeping to keep users away from potentially dangerous systems they have no interest in understanding, and that they'll rely on without understanding in situations where they shouldn't. On the other, you don't want to keep out users who are interested in learning.
> But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
That's where the whole "Not everything is idiot proof" thing comes in. The distribution is pushing the responsibility on users to vet what they do, across everything, not just installing AUR packages, so naturally this also applies to installing 3rd party software.
If you don't know what to look out for, maybe don't install stuff you don't know what it will do. Sucks as an answer if the distribution is looking to "Make it as easy as possible for every user" but that's not Arch Linux ultimately, it does ask you to care about things like that, if you don't want to, it might not be the OS for you. And that's of course OK and not something bad. I know this sounds like gatekeeping, but it's more of a culture difference than anything, and probably not even a problem.
> distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves
That'd suck, but not the impression I've got from CachyOS. There is a FAQ entry that seems to get the gist of AUR correct, that it's basically random software from random users, nothing is assumed safe: https://wiki.cachyos.org/cachyos_basic/faq/#aur-safety-pract...
> this is just a wide cultural difficulty with Linux, and there isn't a clear answer
I don't think "a answer" is needed here. What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing. Some distributions are for making things "easy for newcomers" or some focus on "best UI and UX" and others "most barebones for experienced users to setup themselves", and all of them as valid as the other. The tricky (and slow/time consuming) part is that you have to try a bunch before you find which one(s) aligns with your own perspectives and ideas.
Ultimately, users can learn best together with distributions that align with how they think and want to work.
>What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing.
Oddly enough, when I was writing that, I wasn't thinking about Arch, but Ubuntu. Years ago, I can remember a situation of a PPA being used for developing something I was involved in somehow, and while the PPA specifically noted that users shouldn't use it, they just did anyway, because they wanted what they saw as the latest and greatest versions of those packages. When the PPA owner added a package that set the default wallpaper to a warning about adding the PPA and updating all packages from it blindly, the users blamed them, rather than understanding the message. At the same time, I was actually using that repository legitimately, and it was useful.
So 100%, I agree that it's highly dangerous that the distro's the next tranche of people unfamiliar with linux (gamers dissatisfied with Windows) move over with, are based on hecking Arch. It feels like a massive upcoming footgun.
I think the issue is those repos being based on Arch though, not Arch itself.
To be fair, among all the linux users I know, no one except developers/cs-adjacent would actually get hit by this. The point is that "noob users" use packages that are, to put it short, maintained by a big company. Or it's something that's there in the official repos. And the big companies always maintain their own supply chain till the end, i.e they maintain their aur packages or their curl | bash endpoint themselves. So it ends up being alright.
Stuff that tinkerers use is often some random fork of a fork of a gitHub repo, maintained by someone else, and the aur package maintained by a fourth person. That's where the mess is. Thankfully, these are also the users you can expect to read a pkgbuild diff.
> At that point, what is AUR actually offering that installing the upstream package isn't?
It produces package files that pacman can use. Sure, you can curl|sh or whatever, but that's a good way to litter stuff all over that you can't track or uninstall cleanly.
The same sort of review you'd do if a stranger sends over a project and says "compile and run this" and you actually want whatever it's supposed to do, so you start looking through it.
> 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
That's very suspicious if the package you're about to install doesn't seem to actually need those things. Since "AUR === random strangers on the internet with zero trust", then you need to pay attention to those sort of things.
> 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.
Yes, indeed. Same as if you come across a random C++ project on GitHub with 2 stars, do you just pull down the source and compile willy-nilly? Probably not, you carefully inspect it can actually do what you want, how it does it, and so on. AUR is basically like GitHub in this case, zero peer-reviews and users fully responsible for whatever they install.
> At that point, what is AUR actually offering that installing the upstream package isn't?
PKGBUILDs, so you don't have to write them yourself. Not more, not less, just a central place for random strangers to share PKGBUILDs that may or may not work for others.
I hear you, but consider xz. I'm a professional with decades of experience and I'd be lying if I said I'd have caught that. How long would an audit have taken, realistically? You're not wrong, but I don't think the GP is, either.
Yeah, xz found its way to official repos, that's way more disturbing and scary that this (faux) issue about malware on AUR/user-generated websites.
I don't review updates to official packages on Arch, I don't think most people have time to do so, it's just way too much. Things change when we talk about AUR though, as those aren't vetted, those you need to take the time to review, otherwise you're basically installing completely unreviewed software from strangers on the internet.
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.
I did the malware check using Claude, providing it with the same list (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.
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.
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.
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.
Linux distributions are. They all have maintainers who vet packages and take responsibility for them. Arch Linux does too. The inherent untrustworthiness of the AUR was always made explicit by the Arch Wiki and the culture surrounding it, unlike programming language package managers like npm and pip.
Having trusted community members vet packages is a good system, but how much does it really scale?
1. The whole point of the AUR is that the demand for packages outstrips the volunteer effort to provide secure packages.
2. There are about a dozen major package systems for Linux, with a lot of duplicated effort in packaging the same software for slightly different systems in slightly different formats.
> Who is doing package management right these days? Who is doing it securely?
The malware was limited to package sources that I understand to be disabled by default, if you're using Arch Linux. These package sources carry clear warnings that the packages they provide are controlled by third-parties and entirely unvetted by the distro maintainers. [0][1]
If your assertion is that any package management system that permits the installation of packages that aren't vetted by the maintainers of the -er- OS that uses that package management system is "not doing it securely", then the only one that's even vaguely "doing it securely" is Apple's iOS.
I'm of the opinion that permitting users of a general-purpose computer to install arbitrary software is a good thing, and is pretty much the entire point of a general-purpose computer. I'd call computers that make that effectively impossible "appliances". There's very definitely a place for appliances, [2] but seeking to turn every computer into an appliance is massively destructive.
[2] Reliable computers that you never have to think about because they simply never fail to perform the useful tasks they were designed to do are great.
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
We’re using an internal package repository that acts as a gateway to the public package repositories, except it can have custom rules such as “min release age 30 days”, and can also give logs about which projects have actually downloaded a specific version.
It’s so much overhead and auditing to enforce compliance across the thousands of node microservices though.
And you and me would be better off for it. You can rely on such insanely complex technologies that have required millions of man hours to develop in which even the most knwoledgable will lack a complete understanding, or you can live within your station.
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.
> 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.
`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).
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.
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).
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'?
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.
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.
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.
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.
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.
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.
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)
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.
> 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.
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.
`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious.
(It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)
But it's one middle man less.
Git repo have been attacked other times in the past, but a 500/1000 stars project still sounds more trustworthy than a user repository managed by randos with a couple of upvotes. I still use the aur for simple cases, but when I see aur packages depending on multiple other aur packages I immediately leave.
and how many of others do the same? At least I'm not.. Happily I have only a few aur packages
I'd recommend that you do – it's not very taxing, and if you only have a few then you won't even be doing it much. I'm not auditing the program code itself (where even available), literally just checking that the AUR package actually installs what it says it does/I expected.
Does it also show each patch involved?
It shows the overall diff since last update, not patch-wise. But it does show any extra patch file, install script, etc. – not just the PKGBUILD – if that's what you meant.
The manager I use (paru) does, I'd be surprised if yay doesn't.
It does, but there's a y/n question of whether you want to see the patch
People continue to criticize Arch for being elitist or gate-keeping to keep casuals out but there are clear benefits by not allowing dangerous things to be simple. This is true in many aspects of life.
After using Void Linux I switched to `aurutils` to get a similar separation on Arch. I can easily maintain a local AUR repo by compiling/making my own binaries and can use `pacman` to install and manage them which improves the upgrade process overall.
> People continue to criticize Arch for being elitist or gate-keeping
I have the complete opposite experience. Arch makes it easy to get in and get hacking right away. Their beginner guide's on the wiki were a gem 10-15 years ago... made it super easy to get up and running. I don't have the time these days to tinker - but boy do I love some Arch.
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.
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.
You then get the advantage of the OS’s package manager accounting for everything, however. It’s quite nice to not wonder whether there’s random stateful detritus throughout your system and what it might be affecting. (OK, to be honest there still will be, but much less of it, and a greater part of it will be attributable.)
I think the existence of the AUR puts less pressure on the official repository to have all popular software.
I think it's also a bit of a testing ground for the main repos as well. I maintained the `ruby-build` AUR package for a couple of years after the previous maintainer wanted to step down, but they eventually added it to the main repos and now it's maintained by one of the official people. (I don't recall ever having to do more than paste in the new release tag into the PKGBUILD each time and then generate the new .SRCINFO and checksums in terms of actual maintenance, although I'd test locally first before pushing of course).
I’ve seen automation scripts for this process of updating packages.
Makes sense that the most popular AUR packages will be candidates for the main repo.
I only saw automation around this for the first time earlier this year when noticing that a package was multiple versions out of date and tracking it down to a bot (in the pre-LLM sense) on Gitlab for the package that gave a false negative on a version update due to the format of the upstream git tags changing (either they added a `v` to the beginning or removed it, I forget which). My takeaway from that experience is that while automation can be nice, I'm not convinced that the benefits outweigh the potential for bugs like that if it relies on invariants like git tags that are realistically not something that all upstream maintainers are going to be pedantic about keeping standardized.
I understand that having a relatively small number of people maintaining a large number of packages makes it burdensome to manually update everything, but on the other hand, nobody asked me before promoting the AUR package I maintained to the main repos, and I would have been happy to keep doing it indefinitely! I'm not a "official trusted contributor" by any means, but I also know that I would have kept doing what I already did for years in exactly the same way without any issues, so I can't help but feel a bit like like a known good with hypothetical risks was thrown away for something that will produce at best the same results with less severe but more concrete risks. I wish I had a solution for not getting stuck at that local optimum, but incidents like the one in the article will only make it more of an uphill battle.
(edit: to clarify, I'm not proposing that the package should have been left in the AUR, but that I wish there were a way for them to have just let me keep maintaining it as an "official" package. Maybe something like the kernel model where someone trusted could vet the PKGBUILD updates I do and decide whether to merge them or not rather than doing the same but with a bot, and then maybe not noticing that the bot is silently failing...)
AUR and similar repos for other distros scare the hell out of me.
Tutorials using them are so widespread… Start feeling like a weirdo for not wanting to give an unknown rando full indefinite root access to the system, with virtually zero peer review… all to install one version of a package where updates are undesired or infrequent…
You don't have to. The AUR is just a bunch of PKGBUILD text files, which if you don't feel competent enough to read and understand and trust, you can create your own local versions of and install from. It's just a recipe file that says download a program from this github URL, make sure the hash matches and then extract it and move the files to system directories.
> typoquatting
Perfect demonstration!
This sounds like your update process is quite involved then. Or do you just not do it?
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.
I don’t bother with wrappers, why does it need to be easier than git clone + makepkg -i?
Then I just update when I need to update
The wrapper will give you a nice diff of what changed. You can do that by hand, too, though.
Wrapper is really helpful for every time you do pacman update for official repo, you should recompile all of the AUR repo as well, otherwise you'll be in the land of 'partial upgrades'. Some packages don't complaint too much, while others do
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.
Better would be to namespace AUR packages. That way, ownership is not lost and we don't need orphaning at all.
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?
I mean we can talk about the actual naming scheme but essentially yes.
It is also an explicit signal of someone different taking over the ownership.
There is no official tool to download aur repos, so that’s up to whatever you do.
I've used three in my career as an Arch user:
yaourt
yay
paru
https://github.com/Morganamilo/paru/issues/1563
> 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...
[2] https://github.com/zqqw/pakku
> 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.
Why not? I agree some limits should be added, but also shouldn't be too limited, then lots of things that could be properly maintained, won't. Maybe limit adoption to one package a month or something, to users registered since some date. But no one has automatic (& unreviewed) updates applied to their locally installed AUR packages (that'd be utterly bananas) so the attack vector is already pretty small here.
> 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.
No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-where-it-is-uploaded on GitHub. The code itself is dynamically renamed in its methods, re-used shuffled offsets for encrypted symbols, among other things. It's a mutating malware and the worst enemy from tools that rely on signatures.
Ironically, APT28/29 is somewhat relying on Microsoft being too slow to auto block users and repositories on GitHub that are the C2 infrastructure. Think about that for a second what this implies for your cyber strategy.
By the time you're able to scan signatures or "strings" you're already playing a cat and mouse game with a fully automated botnet, which you will never win. The only other ones I've observed during the last week that seem to be able to track this malware implant's changes were socket.dev. ALL other supply chain tools didn't even know about Miasma and re-invented it as a new campaign. They didn't have the skilled enough people nor toolchain to reverse the malware payload quickly enough to be able to keep up every 24h when they push out a new adapter for another ecosystem.
By fully automated I mean they're already using the credentials they stole less than 48 hours ago from a different package ecosystem, because the email addresses and names etc keep appearing from people who likely didn't even understand the impact of this self-spreading worm.
And having an IOC that checks for, let's say, any package that depends on bun won't help either because the malware will just use external means to re-download it. See the second PyPi campaign, where they just changed the dropper to use compressed WHL files and the setup.pth files that are auto-executed to download the dropper. They changed this after the PyPi maintainers flagged the first wave of malware droppers from the RedHat campaign.
As long as the package managers in those ecosystems aren't fully rewritten from scratch to accomodate for chroots, sandboxes, network and domain logs that are _only allowlistable per entry_ this won't change, and will stay being a feasible malware deployment strategy for supply chain attacks.
Repo for Mitigation Tool (I'm human so I play catch 21 with an LLM powered botnet) [1] ... Tech details in the blog post [2]
Also this is a problem across all package managers. Composer is also affected. Rubygems is also affected. NPM is also affected. PyPi is also affected. Go is also affected.
Nobody is talking about this, and I think this should be more openly discussed how much negligence and external trust we put in package managers in general. This really needs to change.
[1] https://github.com/cookiengineer/antimiasma
[2] https://cookie.engineer/weblog/articles/malware-insights-mia...
With this _actual_ attack, it would have been trivial to detect. The signature was:
1. Orphaned package adopted
2. Has post-install hook added
3. Which uses npm or bun
Yes, you're right - detecting this could have led to a more sophisticated attack. Security is always a cat and mouse game. The purpose isn't to stop every attack - it's to raise the costs for attackers and the visibility for defenders.
Any attacker who wants to attack 1000s of packages is going to necessarily leave some signatures, unless they're extremely careful. If they change one thing but not another, you can tie them both together.
Think of this like email anti-spam. It hasn't gotten rid of spam, but it has made it much more expensive to operate.
Combine this with a minimum package age to give the scanners time to run and humans time to inspect, and the ecosystem as a whole gets much more secure.
Security is not always a cat and mouse game.
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
Here is how I did it :
Get a list of installed packages originating from AUR using 'yay' :
Get list from https://md.archlinux.org/s/SxbqukK6IA# : then : should spit out the packages that are in both files, hence were compromised at some point, I guess.Thank you for this! I only had two on my system, thank goodness. I have uninstalled both.
libgdata 0.18.1-5 qt5-3d 5.15.18-1
Have you checked the install date? I'm not sure which are the compromised version numbers, but if they were installed before June 10 you're probably safe. (I think libgdata 0.18.1-5 used to be on the main repos in February, and has recently been downgraded to AUR, so you may be fine).
Only packages from AUR have been compromised, meaning a normal update `pacman -Syu` won't install them, they'll only be installed by `makepkg` or AUR helpers (such as `paru`, which asks you to review the PKGBUILD diff).
Also, if you had installed a compromised version, uninstalling the packages is not enough, you'd probably need to reinstall your system and rotate all credentials. More info here and on the linked blog: https://discourse.ifin.network/t/400-aur-packages-compromise...
These were installed before June 10th I am almost certain. I will read that link just to be safe!
Looking at my pacman cache both of these versions existed on my system before June of this year so I think I am okay.
I love that even when trying to put malware into Arch Linux AUR, the malware is still distributed through NPM. Legendary platform.
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.
Also see: https://github.com/lenucksi/aur-malware-check
How did emacs-magit got affected? It does not have any javascript to my knowledge
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.
"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
This is like saying a user who clone a random git repo is not to blame and git-scm should do more to prevent cloning of malicious repos. If it is not official, it is your job to review, if you dont like it, use iOS instead of Arch Linux.
If you crash your car, you are liable for the accident. If you aren't ready for that, take the bus.
More power = more responsibility
> If you crash your car, you are liable for the accident.
Because I didn’t go through all the blueprints and find the flaw that led to the crash. This is a dumb argument. It’s also the one the AUR appears to be making.
No, it's completely valid. The arch home page warns you that you're the one responsible for your system, and get to keep both pieces when something breaks. Everything is assembled with this philosophy in mind. This message is reinforced ten times more before the system is even installed and is up and running.
If this is not for you, that's fine, but it's been working very well for some of us for... decades, at this point? I'm not amused by the amount of people here wanting to turn arch into another Ubuntu, most of them having zero familiarity with how the AUR works, or arch more generally.
>but it's been working very well for some of us for... decades, at this point?
but it's worth asking why it's been working well. Has it been working well simply because it's been a niche ecosystem, or even because you wouldn't have known if it didn't because nobody did security audits?
The Arch distribution model, which operates like the Javascript ecosystem, as in having a barebones core and then a zoo of unregulated third party community packages does not seem fine these days. As it became more popular it has naturally drawn attention and from that moment on you're just screwed because you have no security infrastructure. Arch pretty much lived off security through obscurity.
And in particular with the popularity of these spin offs, I forgot what the name of the tiling wm thing is that got very popular, I think a lot of users are not aware that they're doing the software equivalent of buying medicine off craigslist
> The Arch distribution model, which operates like the Javascript ecosystem, as in having a barebones core and then a zoo of unregulated third party community packages does not seem fine these days
It's hard to take the rest of your comment seriously when you don't seem to have a basic understanding of the parts involved here. Arch's distribution model isn't at all like npm (which I guess is what you're actually talking about here), but the AUR specifically is pretty similar to npm. But the AUR isn't Arch's main distribution model, and the official Arch repositories contain a ton of packages in the core, so not even the "barebones core" is correct here.
Arch has pretty much lived off the experience of its users, which is the entire purpose and value-proposition of the OS. You want someone else to be responsible, you're welcome to use the countless of other distributions, Arch is quite literally not the OS for a "Don't read anything and press Update, hope for the best" experience, and I hope the core team continues to push back against that, which they've done for decades at this point.
It's sad, because overall you have a point somewhere there but the big misconceptions kind of hide that message though.
>But the AUR isn't Arch's main distribution model, and the official Arch repositories contain a ton of packages in the core, so not even the "barebones core" is correct here.
I don't think that narrative is supported by the numbers. Arch's repositories are about a magnitude smaller than either the AUR or "batteries included" distributions like Debian. (about 10k to 100k packages), there are more people using Arch derivatives than arch, and according to some community polls, granted I can't verify their methodology, something north of 90% of arch users use the AUR.
If you look at the most popular packages in the AUR, it's the most popular web browsers, virtually every VPN client, popular professional software like davinci, incredibly popular messaging clients, Spotify, Zoom, billion+ userbase software and the vast majority of password managers.
And if you look at who maintains those, it isn't the company, in many cases it's a random pseudonymous user who doesn't show up on Google. And I don't get this strange aggressive tone of suggesting I use something else. I do already, because as should be obvious I think that's a bonkers security model, but it deserves to be pointed out.
I do not think that the majority of people running arch today in practice realizes that their password manager they installed from that repo everyone uses is managed by an absolutely random person on the internet.
> I don't think that narrative is supported by the numbers
Why are you looking at numbers? Arch Linux's official way of distributing software to it's users are the repositories called "core", "extra" and "multilib", anything else than those are "unofficial" and user's responsibility to how they handle it. No need to look at any numbers, literally go to Arch Linux's website and read how it works if you don't know since before.
> there are more people using Arch derivatives than arch
May be, find it hard to believe that's true outside of gaming, but regardless, that doesn't mean suddenly the AUR becomes safe. And if the complaint is about how these Arch-derivitives educate their users, go to their message boards and share this, that has little to do with Arch Linux itself, literally why there are multiple distributions in the first place.
> something north of 90% of arch users use the AUR.
Yes, like me, and probably every other Arch Linux user. I'm sure every developer on macOS at one time uses the terminal, does that mean "rm -rf" suddenly needs to go away?
> it's a random pseudonymous user who doesn't show up on Google
So what, why it matters? All that matters is that the package does what you expect, and use official sources if that's the point. My password manager's AUR package is built by someone I don't even recall the username of, is this a problem in practice? No, because I do what my OS tells me and reviews random 3rd party software I download from the internet. Every time I upgrade, I see that the only thing changing is the URL which points to the official domain, and a content-hash, that's it. The user could be a pirate in Somalia for all I care.
> I do not think that the majority of people running arch today in practice realizes that their password manager they installed from that repo everyone uses is managed by an absolutely random person on the internet.
I think if you look at a certain sub-section of users who install and do things without thinking, you're absolutely correct. But I don't think the rest of the user base who uses Arch for the very value proposition it offers, should suffer because there is a small sub-section of users who install OSes based on what influencers are pushing to their viewers today.
Uh but this isn't random git repos these are packages available through the OS's repos. Why does the AUR even exist if not for malware distribution?
It's an uncontrolled free-for-all disguised as a watering hole. If they can't do the most basic of housekeeping it should not exist full stop.
They *are* doing the basic housekeeping. What do you think this announcement is, if not exactly that? AUR is very clearly documented as user-submitted, and automatic installs from it are heavily discouraged by the maintainers for this reason. Malware aside, there is very little quality control, and a poorly made AUR has the potential to break the system pretty badly. (Though, in my experience, most of the useful AUR packages are trivial to remove if something goes wrong.)
The officially maintained repositories (which are part of a default installation) were not affected. Users need to go somewhat out of their way to use an AUR.
The definition files are all plain text and not especially complicated. It's not too difficult to glance at the file before doing an install to get a basic idea of what it's about to do, just like you should do when running a random shell script or cloning a random git repo. Indeed, most AURs are implemented by cloning an upstream git repo and configuring it so it can be built. The same basic threat model applies: Do you trust the install script? Do you trust the upstream URL whose code it is about to compile?
i read all the pkgbuild diffs, still doesn't give me a good sense. sure, i can verify that it's coming from the official repo but even then there's no guarantee that there isn't junk in there or that the git ref is actually pointing at the right thing.
it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.
> it would be better if there were stronger community moderation and review that has stamps i can trust rather than this idea that eyeballing build scripts is a reasonable security posture.
Ok, so instead of having a reasonable security posture yourself, you'd rather rely on a number of random strangers who've eyeballed the PKGBUILD instead?
Generally, I think Arch tries to prevent users from relying on bad signals, and this principle might be applied here too.
> i read all the pkgbuild diffs, still doesn't give me a good sense. sure,
Do you have an example of a diff that doesn't give a good sense? I review all my diffs too, but I feel like all of them give me a good sense if it's safe to install or not. I mean, why would I otherwise, what's the point in reviewing if you don't use it to make a decision if to install it or not?
pretty much all of them. the diffs only really show that it's coming from the same source, the changed hash and maybe some urls for some patches. actually looking at what is in that changed hash is a much more complicated story. this gives end users a false sense of security ("i read the diffs" -- not really), and attackers a clean vector (all it takes is one bad commit that might not even be on a real branch, or linked patch or late download dependency in the package itself).
> the diffs only really show that it's coming from the same source
What else do you have to review? Both in the cases of binaries and source, the idea is that you trust upstream already, otherwise you shouldn't install software from them. And since you trust upstream, the only thing you need to review in the PKGBUILD is quite literally: Where is this stuff coming from, is it the official domain/repository? Are there other non-official dependencies? Are there patches applied?
Once you've reviewed those, you're done, and as safe as if you installed straight from upstream, zero false sense of security here.
You're mixing concerns here, as what you describe is completely different issue.
blindly trusting upstream is not really a reasonable posture. that is pretty much the source of all software supply chain attacks.
there is work involved in figuring out how to get the complete diff of the code and dependencies that are included in the change, plus review time. this could range anywhere from 5-10m to 1h per package updated- if not more.
Well ArchLinux has a product for you if you want packages that were vetted: the official repositories. AUR is just a centralized place to put user created packages, like npm is a place to put user created node packages.
Nothing is "disguised" here. Arch Linux makes an enormous effort to warn that due dilligence is required before installing things, and to dissuade users from using the User Repository at all, to the point of not offering package manager support for it. The wiki even cites previous instances where malware was discovered in the AUR packages.
The only way you could possibly not be aware of the AUR's nature as an "uncontrolled free-for-all" is if you didn't read the Arch Wiki, and anyone who doesn't read the Arch Wiki should not be using Arch Linux to begin with.
"Uncontrolled free-for-all" is exactly the status quo of programming language package managers such as npm and pip. It's just as easy for total randoms to sign up for an account and push packages on those services as it is to push a package to the AUR. Only the AUR made the lack of trust explicit and part of the culture.
> these are packages
PKGBUILDs are not packages. They’re (user-contributed) instructions on how to build packages.
> available through the OS's repos.
No. The AUR is a platform, similarly to NPM or PyPI, that allows users to upload PKGBUILDs. It is not part of “the OS’s repos,” and it says that loud and clear, multiple times, including on the front page.
[flagged]
You seem to have a wild misconception of what the AUR actually is.
It'd be more like a public toilet anyone could urinate in, and you lick the floor right next to the toilet and then is surprised that it tastes like pee. Of course there is pee on the floor, anyone can pee there!
Better analogy would blaming a supermarket that hosts an outdoor farmers market because you contracted food poisoning from a stand owned by someone else - NOT for buying food from within the supermarket itself.
Meanwhile one of the other customers has norovirus and is deliberately touching everything so others contract it.
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.
The BSDs prevent this by never having allowed random jamokes to upload Makefiles into the ports system.
Yeah, I've prevented this locally too by never building such a platform in the first place, always the best solution!
Jokes aside and just in case, you do realize ports and AUR have two very different models? Ports is more similar to the official Arch repositories, which obviously doesn't suffer from the same problem, and AFAIK, there is no BSD-equivalent of AUR.
BSD is cool and useful for lots of reasons, but comparisons based on misunderstandings helps no one :)
There is pkgsrc-wip which is similar but run by one person who does at least some checking up on new users. AUR is just gigantic in comparison; pkgsrc-wip has about as many total packages as AUR has updated in the past week.
https://www.pkgsrc.org/wip/
But why check the user instead of the actual code? That's like asking people to checking the GitHub user before they install a program from GitHub, instead of the program itself! Ultimately, the PKGBUILD is the only thing that matters here, not the author or how many others reviewed it.
That isn't what I ment, I should have said that the person who runs pkgsrc-wip helps submitters get the package correct (which can be more challenging than PKGBUILD since it is a more strict system and unless it is a Linux only package is more likely to need patches). Thinking about it more it isn't really the same as AUR since as I understand it packages without issues are likely to get into pkgsrc proper in most cases so it is mostly WIP as the name suggests (although not entirely as I recall, at least last time I used it). So you might be correct that there isn't really anything similar in the BSD world.
In this case even if you skimmed it you likely would have missed it since the malicious change was adding a new dependency called "atomic-lockfile".
I'd be surprised if you did it as a Debian user!
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.
How is that relevant unless you read the make file?
If you don't trust upstream, a PKGBUILD from AUR is the least of your problem.
> If it's a binary package, how do you do that?
You find one that builds from source, or you still review PKGBUILD and friends and lean more on evaluating the reputation of upstream and its maintainers, or you simply decide never to install binary packages. Your policy is yours to decide.
> Putting this on users is not a tenable solution.
The alternative would be to not have an AUR. Archlinux has official package repos where packages are vetted. The AUR (Arch User Repository) is not that. The AUR is there to provide greater variety of software than the official repos can, and it does that by not incurring the cost of being individually maintained by volunteer Arch staff and developers. It needs to not incur that cost for it to exist, otherwise it'd just be the official repos. It's like github, but limited to repos with PKGBUILDs.
> The alternative would be to not have an AUR
And in this alternative past/future, everyone is using GitHub to host their PKGBUILDs instead, then someone gets tired/lazy and builds one repository that indexes those, and we have ArchPacBrewRepository or something, and very same issue appears again, unless people change their approach to installing random 3rd party software.
The AUR being hosted by the Arch project on the same domain gives an air of authority and reputation to it which is misleading.
Ask an LLM to assess the package and do a web search for you. Nobody is installing tens of packages a day, you can take a few minutes to consider what you are installing. This isn't blaming the user, it's basic digital hygiene.
Lets take two real and random examples, and I'll share what I'd look for:
First, very easy one, we want to install Brave, so we find https://aur.archlinux.org/packages/brave-bin. All the dependencies are in the official repos already, so those we trust already, you open the downloaded PKGBUILD and you find it's downloading a binary from github.com/brave, you check to see it's the official GitHub profile/organization that you expect. Quickly scan prepare/package for anything out of place, like downloading more files not defined in "source" or whatever. In this case, "suid sandbox" stuff should make you investigate closer so you understand what that stuff does, many things related to Chrome has things like that. That AUR package also has a brave-bin.sh, so a look through that would make sense. AFAIK, everything checks out, this is literally just downloading the official release from GitHub, and extracts it into the right place, so if you trust the GitHub org/user, you can trust the PKGBUILD. The PKGBUILD also seems to be officially maintained by Brave themselves, so probably already there you can verify the AUR user and be done if you feel lax.
Second example is unofficial package, https://aur.archlinux.org/packages/lmstudio-bin, maintained by noureddinex and created by MadGoat, neither which seem official at a glance. Read through the comments to see if anyone else flagged anything, seems fine so again go read the source of the package and the PKGBUILD. PKGBUILD seems standard, downloads something from "installers.lmstudio.ai" so first thing to check is if that's actually the official website, so use search engine to find official website, copy the URL of the download, verify it's the same. In this case, lmstudio.ai is the real website, but download URL on website ends up being "https://lmstudio.ai/download/latest/linux/x64" in the HTML/DOM, so use "curl -v -L $URL" to see redirects, and then we've confirmed installers.lmstudio.ai is actually what they use for official releases. Read through "prepare" and "package", both seem standard and fine, then look through the rest of the files, all of them seem fine, mostly maintenance scripts for the AUR package itself. Package seems fine as a whole, and we could install it, if we're willing to review it again on upgrades in the future.
This is basically all you have to do. Writing what I did while doing it, made each "review" take maybe 5-10 minutes, and it isn't harder than that, regardless who the user is. You just need to know what to look for, and think how you'd "officially" install it anyways. And if what the PKGBUILD differs from what you'd imagine an "official install" would do, investigate if it makes sense and if not, don't install the package, maybe leave a comment for others in AUR to dive deeper.
Question is if this would be thorough enough for this attack? A package with a slightly more involved build process, maybe some patches because it was made to build on a different distro. Maybe you've already installed (and thoroughly inspected) it before, so you're only updating to a newer version, so you're not as thorough with your review. Or an xz-style backdoor.
Yes, it'd be enough. If a package you're using suddenly adds new 3rd party dependencies, you confirm this is actually needed, and if not, you know something is up. When you install software from random strangers, you have to be vigilant and consider the implications of what you do.
I recall the same situation recently with yt-dlp, as they started to depend on a JS engine for some captcha stuff or related. So when you see that, you need to adjust the mindset of "ah whatever it's probably fine" to "Ok, why are these changes actually here?", and if it's not worth reviewing, you might want to reconsider the approach of installing random binaries from the internet that are flagged as unreviewed.
It’s free lines of code on the internet that you are going out of your way to run on your own machine.
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?
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.
If I understand, the malware is installed via npm from some subshell. But yeah I totally believe you have a detailed review of every package-lock.json and etc.
What is npm?
I installed dwm from AUR once, then Prusa slicer.
Dwm PKGBUILD lists patches, so it's kind of obvious one needs to check them to choose what patches they want.
Prusa slices is downoaded from the official website.
I think you live in a different world ;-)
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.
It would be better if software would be forced to have something like a very advanced manifest file, with requested permissions. Malware has to eventually communicate with endpoints, so a declared whitelist of endpoints should definitely be part of such a manifest. Some wrapper program could set up a namespaces that allows just what is requested. Any software that requires `endpoints = [.*]` would make it obvious to the user that it is a really dangerous piece of software. Your code editor should not ship like that.
The first thing I can think of in this direction is flatpak, but that is really coarse grained, with defaults that are very lax. Also flatpak-like solutions do not expose an api to the wrapped application, which is both a pro and a con (a con when you consider installing application plugins requiring further permissions).
> 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.
> doing their due diligence (and more)
Do you know how? This sounds like an unpractical high amount of time consuming task.
It really isn't, made a short tutorial just for you (and other's): https://news.ycombinator.com/item?id=48518704
[dead]
> And what if upstream is problematic?
The same as when you install any software on macos or windows, even proprietary ones, that may themselves depend on third party libraries.
At every stage of development there is a possibility of malicious code being introduced.
I review the source code of every AUR package I install. It's not that difficult to do some basic due dilligence. Now with AI it's even easier.
> 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?
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
There's some big stuff in AUR like the binary VS Code and Chrome, fwiw.
I wouldn't those programs. You have the corresponding FOSS versions (code-oss and chromium) in the main repository. Chrome is basically spyware.
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.
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.
Stupid or rather low-friction on purpose?
Stupidly low friction. Consistently failing to learn from the mistakes of package managers is bad enough. Failing to learn from your own is another level.
“Learning from your mistakes is good. Learning from the mistakes of others is better”.
For all its flaws, at least Cargo attempts to do that. AUR does not. No other package manager this regularly has hijacking problems.
Both. And that's an even worse combo, making stupidity frictionless.
Since you are using the official repos thats not an issue. The issue is when the package creator is some rando on the internet.
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.
How much work is created (and for who) when a package is moved to the official repository?
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.
> 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.
How would this help against someone submitting an actual, non-compromised version bump, then adding malware once it's accepted?
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 :)
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.
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.
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.
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).
> 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 | 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.
GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks.
GitHub also actually protects against repojacking and tombstones username/reponame combinations (that exceed a certain minimum popularity) and never lets anyone ever use them again.
The utility of AUR is also really based around being able to reuse the same repo without having to re-vet every single time. This kind of attack, that forces you to re-vet on every single upgrade so that trust inherently can't be established, is also not GitHub's model at all.
And go has a software package manager that heavily uses GH for distribution, and is arguably more VCS decentralized, but isn't vulnerable to this kind of attack, because it inherts GH's threat model, and doesn't implement the kind of choices that AUR decided to deliberately build into their system.
> GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks.
Changing your username would let anyone reuse the old username for whatever they want. Probably still today there are bots squatting any renamed accounts. Also, you bet Microsoft would hand over your GitHub username if it was reported by someone who holds a registered trademark in the US over that username, regardless of impact.
> The utility of AUR is also really based around being able to reuse the same repo without having to re-vet every single time.
I don't think they promise that anywhere, nor should you have that expectation. That would be like since you got legit copy from random-website.com/bin.exe today, you'd get that tomorrow too, clearly not true unless you know the owner of the domain or otherwise trust it.
> go has a software package manager that heavily uses GH for distribution, and is arguably more VCS decentralized, but isn't vulnerable to this kind of attack
Unless Golang suddenly have peer-reviewed packages, Golang has exactly the same problem as AUR in that anyone can create packages, and it's up to users to decide what to trust or not. Fair that the whole "orphaned packages" thing doesn't exists in Golang, but I think Arch probably favors stability more than people expect/think, that's why people can continue to maintain packages even though original maintainer disappears. Ultimately it's a trade-off, I don't think there is some absolute truth what is correct or incorrect.
Regardless of who maintains the package, if you use AUR as intended, it seems you'll avoid most security issues. It's when your expectations aren't aligned with what AUR actually promise, that people start getting hacked.
I don't know how it works these days, but a few years ago GitHub was happy to give away usernames from users who haven't touched their accounts in a long time to anyone who asked. Several people I know got vanity usernames that way. All you had (have?) to do is drop an email to GitHub's support.
Only thing I can find on requesting to take over an inactive account is here:
> We do not accept requests to release, transfer, or reclaim usernames on the basis that they appear inactive or unused. If the username you want has already been claimed, you will need to select a different available name unless you are submitting a trademark complaint as described below.
https://docs.github.com/en/site-policy/other-site-policies/g...
Also even the original user renames or deletes their account any popular repos they have will get tombstoned, so the new owner can't recreate them:
> GitHub uses a tombstoning algorithm to reduce the risk of repo-jacking by permanently retiring specific owner name, repository name combinations. The github/cmark-gfm example above is purely hypothetical, because, in that scenario, the old name would get automatically tombstoned. For example, even if an attacker managed to register the username github, they would still be prevented from creating a new repository with the name cmark-gfm because that owner name, repository name combination (github/cmark-gfm) would be permanently retired. Therefore, repo-jacking is only a risk for repositories that fall below a certain usage threshold. We don’t tombstone all renamed repositories because there’s a tradeoff between usability and security: a tombstone is a potential inconvenience for our users which we don’t want to impose unless there’s a genuine security-related reason to do so. That’s why our tombstoning policy only kicks in after the repository has met certain criteria, such as exceeding a specific number of clones.
https://github.blog/security/supply-chain-security/how-to-st...
Github has changed their policy in 2022.
Before that it was possible to contact support to reclaim any username provided that they had no meaningful public repos and they were inactive for a long time. It was at the staff's discretion, there wasn't an elaborate policy of what constitutes inactive, but I've successfully reclaimed a username inactive for 2 years myself.
The old policy was:
> Github has changed their policy in 2022.
Which means that in the age of supply chain attacks, they patched the holes.
Which is exactly why this policy that AUR has is terrible in 2026.
The fact that GitHub didn't have that policy back in 2015 isn't the counterexample that the argumentative crowd here seems to think it is.
That is the GH policy right NOW, in the year of our Dog, 2026.
AUR is pretty grossly behind the curve, and I'll certainly accept that GH was arguably slow about it.
Defending AUR's policy on the basis of GH's policy being shitty until relatively recently isn't a good argument.
Meanwhile sometime around there I changed my GitHub username, and not reading up on the suggested process before doing so. The idea was to rename my account, then create a new account with the previous username, so no one else could squat it, as it's my firstname + lastname and the combination seems unique in the world, so it's basically just me. But a few seconds after renaming the account, it got squatted and even requesting to GitHub to reclaim it somehow, has fallen on deaf ears.
Lesson learned, create new accounts and never rename usernames, regardless of what rules the platform might share publicly.
> AUR isn't a package repo.
What does the 'R' in AUR stand for? Rutabaga?
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.
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?
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.
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.
This.
Who needs social engineering NPM maintainers when there are thousands of freebie AUR ones.
> 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.
Yeah, the AUR is basically build scripts for github repos or a link to someones pre-built binary. It suffers from all the same problems that the underlying infrastructure suffers from. You could very easily argue that since github/npm/cargo/<your package manager of choice> has a supply chain issue so does the AUR.
>`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.
Not all tools are made for inexperienced people. Not everything is idiot proof. This is OK!
In my experience using the AUR:
1. when you first install the package you can read the build script (and you should). These are in a very standard structure, and if the one you are reading is weird and complicated consider not installing it. No one is forcing you to. Almost every build script I read just downloads a build from a tagged github release.
2. when you get an upgrade you are shown the diff. For almost every AUR package I use this is literally just changing the $VERSION variable and the subsequent $HASH of the download. It is trivial to see if anything (in the AUR script) is happening that is sneaky.
It's really not that scary. And if it's considered scary, there are literally dozens of other linux distros (not to mention Windows or MacOS) you could be using instead.
I'm not asking for myself. Yes, I understand the build process, and know what to check. I've also written PKGBUILDs before and have had packages in AUR. I'm sure you understand it too, as well as many people here.
But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
And, again, this attack was a relatively obvious one. Other attacks could be made much harder to notice.
Worse, distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves. Unlike ArchLinux, those sometimes do seem to promote AUR-helpers. In some cases, those distributions are apparently including AUR-sourced packages in their actual repositories.
Questions about these topics often result in typical Archlinux hostility. And in some sense, that's understandable: there are other distributions that most users should be using, and the frustration of people using Archlinux who shouldn't be is wearing. It is nice to have a distribution that offers the flexibility and space for experimentation that Archlinux does. It's one of the reasons I use it on some of my machines, while at the same time recommending against most others using it.
To some extent, this is just a wide cultural difficulty with Linux, and there isn't a clear answer. On one hand, you want enough gatekeeping to keep users away from potentially dangerous systems they have no interest in understanding, and that they'll rely on without understanding in situations where they shouldn't. On the other, you don't want to keep out users who are interested in learning.
> But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.
That's where the whole "Not everything is idiot proof" thing comes in. The distribution is pushing the responsibility on users to vet what they do, across everything, not just installing AUR packages, so naturally this also applies to installing 3rd party software.
If you don't know what to look out for, maybe don't install stuff you don't know what it will do. Sucks as an answer if the distribution is looking to "Make it as easy as possible for every user" but that's not Arch Linux ultimately, it does ask you to care about things like that, if you don't want to, it might not be the OS for you. And that's of course OK and not something bad. I know this sounds like gatekeeping, but it's more of a culture difference than anything, and probably not even a problem.
> distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves
That'd suck, but not the impression I've got from CachyOS. There is a FAQ entry that seems to get the gist of AUR correct, that it's basically random software from random users, nothing is assumed safe: https://wiki.cachyos.org/cachyos_basic/faq/#aur-safety-pract...
> this is just a wide cultural difficulty with Linux, and there isn't a clear answer
I don't think "a answer" is needed here. What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing. Some distributions are for making things "easy for newcomers" or some focus on "best UI and UX" and others "most barebones for experienced users to setup themselves", and all of them as valid as the other. The tricky (and slow/time consuming) part is that you have to try a bunch before you find which one(s) aligns with your own perspectives and ideas.
Ultimately, users can learn best together with distributions that align with how they think and want to work.
>What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing.
Oddly enough, when I was writing that, I wasn't thinking about Arch, but Ubuntu. Years ago, I can remember a situation of a PPA being used for developing something I was involved in somehow, and while the PPA specifically noted that users shouldn't use it, they just did anyway, because they wanted what they saw as the latest and greatest versions of those packages. When the PPA owner added a package that set the default wallpaper to a warning about adding the PPA and updating all packages from it blindly, the users blamed them, rather than understanding the message. At the same time, I was actually using that repository legitimately, and it was useful.
So 100%, I agree that it's highly dangerous that the distro's the next tranche of people unfamiliar with linux (gamers dissatisfied with Windows) move over with, are based on hecking Arch. It feels like a massive upcoming footgun.
I think the issue is those repos being based on Arch though, not Arch itself.
To be fair, among all the linux users I know, no one except developers/cs-adjacent would actually get hit by this. The point is that "noob users" use packages that are, to put it short, maintained by a big company. Or it's something that's there in the official repos. And the big companies always maintain their own supply chain till the end, i.e they maintain their aur packages or their curl | bash endpoint themselves. So it ends up being alright.
Stuff that tinkerers use is often some random fork of a fork of a gitHub repo, maintained by someone else, and the aur package maintained by a fourth person. That's where the mess is. Thankfully, these are also the users you can expect to read a pkgbuild diff.
> At that point, what is AUR actually offering that installing the upstream package isn't?
It produces package files that pacman can use. Sure, you can curl|sh or whatever, but that's a good way to litter stuff all over that you can't track or uninstall cleanly.
> What review should users do?
The same sort of review you'd do if a stranger sends over a project and says "compile and run this" and you actually want whatever it's supposed to do, so you start looking through it.
> 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
That's very suspicious if the package you're about to install doesn't seem to actually need those things. Since "AUR === random strangers on the internet with zero trust", then you need to pay attention to those sort of things.
> 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.
Yes, indeed. Same as if you come across a random C++ project on GitHub with 2 stars, do you just pull down the source and compile willy-nilly? Probably not, you carefully inspect it can actually do what you want, how it does it, and so on. AUR is basically like GitHub in this case, zero peer-reviews and users fully responsible for whatever they install.
> At that point, what is AUR actually offering that installing the upstream package isn't?
PKGBUILDs, so you don't have to write them yourself. Not more, not less, just a central place for random strangers to share PKGBUILDs that may or may not work for others.
I hear you, but consider xz. I'm a professional with decades of experience and I'd be lying if I said I'd have caught that. How long would an audit have taken, realistically? You're not wrong, but I don't think the GP is, either.
Yeah, xz found its way to official repos, that's way more disturbing and scary that this (faux) issue about malware on AUR/user-generated websites.
I don't review updates to official packages on Arch, I don't think most people have time to do so, it's just way too much. Things change when we talk about AUR though, as those aren't vetted, those you need to take the time to review, otherwise you're basically installing completely unreviewed software from strangers on the internet.
So easy to say.
For a distro this popular I’m surprised how much is in unofficial repos(AUR) and not the official ones.
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/c...
But the community repo in Alpine is vetted and reviewed unlike AUR, which is a wild west.
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
I did the malware check using Claude, providing it with the same list (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.
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.
Malware has started sprinkling references to nuclear shit and other strings that trigger model safety so they'll refuse to actually scan them.
Good instinct. I did both. The script came out later.
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?
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.
That’s not so much an example of who is using best practices, as it is an example of who is using worst practices.
> 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.
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.
Linux distributions are. They all have maintainers who vet packages and take responsibility for them. Arch Linux does too. The inherent untrustworthiness of the AUR was always made explicit by the Arch Wiki and the culture surrounding it, unlike programming language package managers like npm and pip.
Having trusted community members vet packages is a good system, but how much does it really scale?
1. The whole point of the AUR is that the demand for packages outstrips the volunteer effort to provide secure packages.
2. There are about a dozen major package systems for Linux, with a lot of duplicated effort in packaging the same software for slightly different systems in slightly different formats.
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.
> Who is doing package management right these days? Who is doing it securely?
The malware was limited to package sources that I understand to be disabled by default, if you're using Arch Linux. These package sources carry clear warnings that the packages they provide are controlled by third-parties and entirely unvetted by the distro maintainers. [0][1]
If your assertion is that any package management system that permits the installation of packages that aren't vetted by the maintainers of the -er- OS that uses that package management system is "not doing it securely", then the only one that's even vaguely "doing it securely" is Apple's iOS.
I'm of the opinion that permitting users of a general-purpose computer to install arbitrary software is a good thing, and is pretty much the entire point of a general-purpose computer. I'd call computers that make that effectively impossible "appliances". There's very definitely a place for appliances, [2] but seeking to turn every computer into an appliance is massively destructive.
[0] <https://aur.archlinux.org/>
[1] <https://wiki.archlinux.org/title/Arch_User_Repository>
[2] Reliable computers that you never have to think about because they simply never fail to perform the useful tasks they were designed to do are great.
It's a lost battle.
Everything will need to be run in a VM separated from your main desktop which should have your data and a minimal amount of apps.
Qubes OS was ahead of it's time.
I think something about the node ecosystem makes it particularly vulnerable. Maybe it's the insane "dry" ethos. Or something else.
Nothing I have ever used has a comparable dependency tree nightmare.
I think most ecosystems have more batteries included than node.
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
Min Release Age of 7-30 days covers the majority of potential issues with 0 effort.
All major Node package managers should support it by now.
Prom was the best IIRC, yarn second, but even npm is catching up
We’re using an internal package repository that acts as a gateway to the public package repositories, except it can have custom rules such as “min release age 30 days”, and can also give logs about which projects have actually downloaded a specific version.
It’s so much overhead and auditing to enforce compliance across the thousands of node microservices though.
That’s a great idea. Maybe use Claude Code with some owasp knowledge to sweep through them and see if there’s anything obvious?
Running external code will always be a risk. Even if it is not intended to be malicious it could still have issues that compromise security.
Read the source. If you don't have the time then you shouldn't run the software.
By “external code” do you mean code that is not written by yourself or the organization you are working in?
The Linux Kernel has 40 million lines of code, I don’t have the time to read that so I guess I better not use it.
And you and me would be better off for it. You can rely on such insanely complex technologies that have required millions of man hours to develop in which even the most knwoledgable will lack a complete understanding, or you can live within your station.
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.
> 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.
> 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).
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.
Yea, but that is to install the package after it was built (or installing dependencies). The build itself is done unprivileged.
[flagged]
I might be wrong, but this situation seems like a signal of desktop Linux adoption growth
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).
Arch has always been script kiddie tier compared to Gentoo lol.
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'?
Seems cheaper (and so far more robust) to have an agent audit downloaded code
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.
The build process is just as vulnerable.
Sounds more midgame.
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.
this
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.
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.
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.
Sadly they forced anybody with an older nvidia gpu to use some AUR package some months back.
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.
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.
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.
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
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.
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)
It will be under control when the underlying issue is fixed
As I undertood it this was mostly orphaned packages?
That's correct, orphaned packages could be adopted seemingly automatically, so someone did and then published malware in bulk.
This makes me want to adopt more packages. Lots of the orphans barely need updating.
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.
> 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.
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?
[flagged]
"linux has no malware, windows bad boooh"
"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"
> central
That will end badly at some point
How bad was it?
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.
I was concerned at headline, then saw "oh just AUR"
Next up, "millions of malicious packages still not taken down on internet"
I wonder what typical AUR usage looks like. I apparently have 27 packages installed and last updated one in November.
There's more than one way but this lists packages not installed by pacman itself:
Only 237 on my 12 year old system but I rarely update AUR packages and usually try to remove unused ones before updating.Who's on Arch Linux btw?
This is my fear with Linux and privacy - malware that leaks private data while using ie Tor, or other "anonymous" programs.
How is it Linux-specific?