Rendered at 08:02:25 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
WD-42 15 hours ago [-]
I’ve been using arch for nearly 2 decades at this point. It’s amazing that the AUR went this long without any serious attacks.
It’s a different world now. I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
sp0rk 15 hours ago [-]
> I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
This has absolutely not ever been the case.
jolmg 14 hours ago [-]
It is, among most users, but it only takes a few abusing that for it to seem like there's none.
EDIT: Rereading, maybe it's that other kind of "hacker"...
m463 9 hours ago [-]
I think smaller "unimportant-ish" communities become larger and attract attention from a wider variety of people.
If 1:10,000 people is an axe murderer, when your community reaches 20,000 people... You have to create an axe-murderer-captcha.
dmitrygr 13 hours ago [-]
> This has absolutely not ever been the case.
I think it was. Eg: on most russian warez forums in the 2000s, it was a bannable offense to crack russian-authored software.
dima55 5 hours ago [-]
This is more due to the special blend of an inferiority complex and a strong us vs them mentality common to far too many Russians.
sp0rk 8 hours ago [-]
I was just exaggerating for effect. Obviously I wouldn't seriously claim nobody ever did something, just that it wasn't what I would consider common behavior.
That being said, I think the particular example you provided is kind of weak. It's my understanding that the behavior you speak of was driven primarily by the Russian government's unofficial policy of ignoring cybercrimes committed by their citizens so long as the targets were not domestic. They were ensuring their ability to continue operation by banning discussion of targeting Russians. This is how groups like the Russian Business Network have been able to flourish.
TiredOfLife 3 hours ago [-]
That usually was because authors were also posters on that forum and offered significant discounts or even free licences
DDayMace 13 hours ago [-]
yup there is no honor among thieves unfortunately
sejje 14 hours ago [-]
yes, hackers are bigger targets imo, not smaller ones
matheusmoreira 1 hours ago [-]
People are warned countless times that the AUR is unsafe, that any random person can make an account and push packages, that you need to audit what you're downloading and that malware has been discovered in it multiple times in the past.
static_motion 12 hours ago [-]
The reason is popularity. SteamOS is Arch-based and in the hands of a ton of people who aren't necessarily that technical. CachyOS and EndeavourOS have become very popular with the increasing adoption of desktop Linux. The AUR thus becomes an enticing attack surface.
fooqux 4 hours ago [-]
I doubt that anybody who is "not that technical" is going to install an AUR package on their steam deck.
TiredOfLife 3 hours ago [-]
All it requires is pasting stuff into terminal. And there are countless guides and videos
jolmg 15 hours ago [-]
Arch is simply getting popular enough to be targeted.
hnlmorg 14 hours ago [-]
It had been for a long time now.
What’s more likely is the effort required for large scale attacks is easier now than ever thanks to LLMs.
al_borland 13 hours ago [-]
> I can’t help but feel there used to be honor among hackers.
My assumption is these aren't so much hackers, as modern day script kiddies armed with LLMs and too much free time.
akerl_ 13 hours ago [-]
I think you've accidentally lumped together "people who work in tech in / around the field of information security" and "criminals".
There have been a variety of cultural elements to people doing security research / hacking on their own systems / etc.
There has never been "honor" among criminals looking to use technology to steal money or steal things that can be converted to money.
ivanjermakov 14 hours ago [-]
I'm surprised installing native software is still commonplace. At least in a world of gaming and professional software it's coming from reputable source, but when it comes to PC enthusiasts we've been walking on thin ice for a long time.
I also believe this is the main reason why web took off: effortless distribution and sandboxing.
michaelmrose 12 hours ago [-]
For open source software it would be a massive increase in development time, difficulty, and continued costs that dwarf income to switch to the web. It would be shocking if it happened not the reverse. This is just for application software how do you replace installing a library or development tool with the web?
It's weird that installing software is weird to you.
cookiengineer 13 hours ago [-]
> What kind of jerk would attack Arch Linux?
The answer is: Russians
Source: I'm the guy that built the antimiasma mitigation tool [1] and tracked their malware campaign iterations very closely.
Set LANG to ru_RU.* and the malware implant stops spreading itself, as with all APT28/29 malware.
Only ru_RU? It doesn't get disabled with, say, zh_CN, ko_KR, or anything else where the script is outside of the Basic Multilingual Plane (AKA ASCII)?
PunchyHamster 8 hours ago [-]
wasn't popular but was low entry attack.
Now it got more popular but still low entry attack.
> It’s a different world now. I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
Not sure why hacker would waste their time fiddling with Arch instead of hacking stuff, everything that they need can run just fine on any of the Debian derivatives.
charcircuit 15 hours ago [-]
Desktop Linux has always been a house of cards in regards to security. I agree it's amazing that it went on for so long, but this was inevitable.
Matl 14 hours ago [-]
With regards to sandboxing etc. maybe. With regards to packages? Official repos support signing and usually rely on maintainers with proven track records. AUR was a honor system and since some people are total basement losers, you can't rely on that.
Alive-in-2025 14 hours ago [-]
We have locks on our doors for a reason. Any software that allows updates and relies on the honor system of "someone else must have checked this" will get hacked. Every day there's yet another certificate or secret stealing infection that is in some random upstream dependency in your dev tools or shell scripts or whatever.
thayne 12 hours ago [-]
> Any software that allows updates and relies on the honor system of "someone else must have checked this"
That is never how the AUR was supposed to work. Updates were intended to be a manual process where the user reviewed changes to the PKGBUILD.
Matl 13 hours ago [-]
Yes, my point being this isn't some 'Desktop Linux security' hole. This was a known and intentional model of how the AUR operated for decades. Unfortunately it was bound to get exploited like this and so it did.
mindlessg 15 hours ago [-]
Castles made of sand slips into the sea, eventually
GreenVulpine 14 hours ago [-]
Better than the commercial alternatives
zahlman 15 hours ago [-]
More so than, say, Windows? Really?
And no, "people using one Linux distro can opt in to possibly getting pwned by each other by making use of a third-party software depot" does not reflect upon the entirety of the Linux world.
nvme0n1p1 15 hours ago [-]
It's funny how these people say Linux security is bad because random people can upload arbitrary files to AUR, but won't say Windows security is bad because random people can upload arbitrary files to Microsoft GitHub.
davkan 14 hours ago [-]
I think the wrongful notion comes from the fact that the vast majority of Arch users use and speak about AUR as if it were a part of arch proper, only paying lip service to reviewing PKGBUILDS, etc. They wrap the default package manager in one that supports AUR and never touch it directly again. It feels closer to if all of GitHub was available in one click through the Microsoft store or windows update.
And unfortunately that’s how arch is mainly marketed by its users. “Arch has the latest everything, if it’s not in the repos it’s on AUR” is one of the standard selling points.
Of course that speaks to how people use linux insecurely not how Linux is insecure.
thayne 12 hours ago [-]
Most AUR "helpers" show you the PKGBUILD and/or a diff thereof and ask you to confirm that it looks ok before continuing the install. At least by default.
Maybe most users just ignore that and always answer yes without inspecting it. I don't know. But the wiki for the AUR and Readmes for many of these tools have warning banners telling you not to blindly trust AUR packages.
charcircuit 12 hours ago [-]
There are subtle things like abusing how github handles forks which can make malicious PKGBUILD a matter of just changing the rev with no hint in the file itself.
thayne 9 hours ago [-]
Perhaps, but it would be pretty unusual to use a commit/hash id instead of a version tag, or the main development branch.
tosti 15 hours ago [-]
MS-Windows gets attacked by the hardware vendors, too.
TiredOfLife 3 hours ago [-]
Yes. Windows has had a built in antivirus for 14 years
charcircuit 12 hours ago [-]
I never claimed that and in fact Windows has had a lot of malware written for it proving it too has bad security.
There are more ways to attack people than third party software depos.
Barrin92 13 hours ago [-]
>More so than, say, Windows? Really?
significantly so. Windows has a coherent story when it comes to permissions and access. Differentiated out access controls, least privilege, UAC, mandatory integrity control and all configured out of the box.
Without AppArmor or SElinux correctly configured, which it isn't on most desktop distributions in the linux world most of your apps can still read anything, there's little sandboxing. The NT Kernel was designed with an object model in mind so you always had the abilities to have rich descriptions and policies for whatever you're handling where all of that is bolted on unix systems after the fact.
charcircuit 9 hours ago [-]
>Windows has a coherent story when it comes to permissions and access.
Yet that doesn't seem to matter much for stealer malware.
Barrin92 7 hours ago [-]
it does matter, things like the Data Protection API do meaningfully reduce what you can extract from a windows system.
Of course Windows regardless has taken the brunt of the attacks because it ran virtually every desktop machine in the world so people go after users anyway. Desktop Linux systems where never economically interesting for malware. But now that they have gained a modicum of traction they're going to get the exact same treatment, hence this thread.
Microsoft doesn't advertise it much but they do have the advantage of controlling their build environments, software is signed etc. A system like the AUR where you pull in unsigned packages from anonymous people with so many arch users relying on it is not going to be easy to address. It lived on security through obscurity.
charcircuit 6 hours ago [-]
>Data Protection API do meaningfully reduce what you can extract from a windows system
It's not meaningfully reduced. The stealer just has to call CryptUnprotectData before uploading it. It's not even like it will show a suspicious prompt to the user, without having to do anything extra the stealer can silently decrypt it.
I agree with the rest of the post though.
tempfile 15 hours ago [-]
I disagree. Maintainers for the major distributions take their roles very seriously, and do a very good job generally of filtering out malicious packages. The AUR is an outlier, being essentially an unmaintained wild west.
saghm 14 hours ago [-]
The AUR is also not really comparable to official distribution package repositories either. Yes, it's hosted by the same people as the official repos that are comparable to what you'd get by default on other Linux distros, but it's intentionally not something that works with official package management tooling. The equivalent would be if Debian or Ubuntu hosted a repo that anyone could upload of unbuilt debian packages while explicitly not offering any tooling other than the usual tools for building a .deb from source files that you manually downloaded from anywhere else or defined yourself.
It's definitely an outlier, but more in terms of being something that doesn't really exist anywhere else, so of course the security model for it will also be an outlier. That's not an excuse for any security issues, but it's not like Arch doesn't have official repos with maintainers who are just as diligent as any other distro. They just also happen to provide a public git server that people can publish packages to with a UI for seeing some of the package metadata; people could just as easily write toolling to automate package management where it looks for a GitHub repo instead of an AUR one to fetch the build files.
graemep 10 hours ago [-]
The Ubuntu equivalent is PPAs.
shevy-java 14 hours ago [-]
Could be AI slop attacks made attacks easier in general. Though, the Arch Linux model was probably never an ideal security model. It seems the easy days of the 1990s are over finally.
Gud 24 minutes ago [-]
The problem is that there is a LOT of missing stuff in the Arch repos.
I use FresBSD, where I rarely run in to this problem, that something is missing from ports.
However, it is a common occurrence in Arch. Which is a shame, because it’s otherwise a fine operating system.
vlovich123 14 hours ago [-]
> The project had suspended new account registration in June. That followed a campaign in which an attacker or attackers created new accounts to adopt orphaned packages and push malicious updates to them that would install malware on user systems. AUR registration was reopened on July 13 after the DevOps team added some minor, and apparently ineffective, restrictions on creating new accounts.
Disabling AUR package adoptions has been like the #1 thing recommended. While it's a positive step, it's not good news they literally tried everything else first. This doesn't speak well to the security headspace of the Arch maintainers.
qwery 14 hours ago [-]
I'm sure the team are having a rough time with all this, but I don't understand the path you followed to go from the maintainers have not taken this action until now to "This doesn't speak well to the security headspace of the Arch maintainers". Or what "security headspace" means exactly.
Yes, lots of people thought disabling package adoption is/was a good idea. It seems quite likely that the Arch DevOps team also could have come up with that one, and they certainly wouldn't have missed all of the people telling them to do so.
It seems to me that disabling package adoption is not a desirable thing to do in general, and can only be used as a stopgap response to an emergency, which seems to be what is happening right now.
"just disable adoption" certainly can't be a long-term solution:
Without adoption, the AUR will slowly fade away as orphaning a package would be permanent.
Maybe the idea is to have some sort of approval process to filter adoption requests? In that case the AUR just dies instantly as that would effectively be another official repo with all of the issues that that would bring.
vlovich123 10 hours ago [-]
> AUR registration was reopened on July 13 after the DevOps team added some minor, and apparently ineffective, restrictions on creating new accounts.
This - they tried this first even though it’s pretty obvious this is an ineffective mechanism to fight security issues around adopting orphaned packages.
“Security headspace” means treating security seriously and acting appropriately and correctly with appropriate urgency. This whole saga they were slow to respond, they took days to actually stop the ongoing attack, and have tried everything else other than stopping adoption of orphaned packages. This should have been the FIRST thing done and only once you have a solid idea on how to reenable then you allow it. And even then I’m not sure orphaned packages are ever suitable for adoption - if you want to take over for an abandoned project, you start your own alias and try to convince all downstream dependencies to change where they point. This makes it adoption by the community which is slow and takes time and won’t be as trivial to convert into a mass scale cyber attack.
That everyone here is “but adoption is required for AUR” makes it clear there’s very limited experience and research on how other package managers don’t have this embarrassing failure (both OS and language ones like node and Cargo which have to deal with far more sophisticated attacks) and this is the way - you don’t allow identity laundering. They are all susceptible to identity laundering by just buying the project (assuming the maintainer is open to selling their keys) but that’s harder to scale by a script kiddie and requires a more sophisticated form of action.
Matl 14 hours ago [-]
Well, this kills a very useful feature of the AUR. It's like Wikipedia disabling editing. So I can see trying other things first before resorting to removing features, but I do agree it should have happened faster.
datakan 14 hours ago [-]
The Arch devs have only ever used the AUR as a toilet where everyone can piss and not contaminate the core distro.
Fedora Copr, FreeBSD Ports, are all of a similar idea. Where Arch screws up is in allowing people to take over abandoned PKGBUILDS instead of making them create new ones.
This can happen to Ubuntu with the PPA's too if someone were to gain control over, say, the Nvidia PPA for drivers. It's happening almost daily with NPM and Github. Supply chain attacks are serious and the Arch devs do warn people about this right off the bat. You don't go installing from the AUR without understanding the risks.
christophilus 12 hours ago [-]
This just made me think: if Anthropic or OpenAI wanted to get some good will, and burn a bunch more investor funding, they'd provide security audits for the most popular N AUR packages for free as a good-will service.
akdev1l 8 hours ago [-]
This is a lose-lose proposition.
1. Lose money burning tokens in all of this stuff.
2. Lose reputation when some malware eventually makes it through
ApolloFortyNine 13 hours ago [-]
>Disabling AUR package adoptions has been like the #1 thing recommended.
Do you have a solution to ever reenabling package adoptions? It's pretty much a must have feature for this to exist long term, at least in the AUR's current state where its a repo your not supposed to auto install from but pretty much all users do.
Really disabling adoptions is probably step 1 to just EOLing the whole thing.
The AUR by definition isn't to be trusted. That's what the official repos are for, you're supposed to read what the package install scripts are doing.
vlovich123 10 hours ago [-]
The solution is to not do it because it’s identity laundering and that’s insecure inherently and not something any other sane package manager supports.
If you want to convince someone “my copy of foo is much better maintained than foo-legacy” you are free to go downstream dependency by downstream dependency and convincing a switch / convincing end users to install yours. You can even have hints to users “hey this package looks to be abandoned - did you mean X”
Pay08 12 hours ago [-]
> Really disabling adoptions is probably step 1 to just EOLing the whole thing.
That's what they should do. The AUR has been a giant fuckup since the beginning, which is especially outrageous seeing as they had the perfect template for it with Gentoo's GURU.
joha4270 11 hours ago [-]
What alternative do you then propose for "I'd like to install this random application which isn't popular/high quality enough to be included in the main repository"? Everyone figures it out from scratch by copy pasting bash commands from stackoverflow or maybe chatGPT these days?
pitaj 2 hours ago [-]
Namespace every package, so you install "somebody/thing" instead of just "thing"
alightsoul 9 hours ago [-]
Or they just install it via random bash scripts on GitHub but that's just pushing the problem into the user.
delecti 16 hours ago [-]
That title had me worried, but the reality seems quite reasonable.
I assumed the goal was to reduce usage of AUR, they've actually remove the ability to adopt (take ownership of) orphaned packages. I'm sure there are legitimate uses of that functionality, but it also seems like a pretty big avenue for abuse.
OJFord 15 hours ago [-]
I've used it (not for abuse). It's simply volunteering to maintain the package after previous maintainer(s) have explicitly disowned it, knowing they no longer have time for it or don't care because they stopped using it, etc.
gchamonlive 15 hours ago [-]
Problem is that there is no KYC process before someone can adopt any orphaned package
OJFord 14 hours ago [-]
Yeah, I don't disagree there should be more of a barrier, I remember being surprised I could just adopt things. Just explaining the intended use.
yjftsjthsd-h 11 hours ago [-]
There's also no KYC process for creating one.
bee_rider 15 hours ago [-]
IMO allowing package adoption makes sense in the responsible/intended use-case: AUR packages aren’t trusted, you have to read the PKGBUILD anyway, so the reputation of the contributor doesn’t matter. Removing adoption is admitting that there’s no way to prevent some users from blindly trusting a PKGBUILD.
Which is probably the best choice, unfortunately.
jolmg 15 hours ago [-]
> I'm sure there are legitimate uses of that functionality
To avoid package name pollution, e.g. having package foo, foo-newpackage, foo-newpackage-updated, etc. each by a new maintainer as the priors get abandoned.
tremon 14 hours ago [-]
With a bit more structure, you could change that to: every package in AUR is actually registered as foo/maintainer under the hood, and installing the package without maintainer name pins it to the currently active version. Package adoption can then be formalized as a new maintainer publishing their own version of the package, and users of an already-installed package need to issue an explicit command to switch over to the new maintainer's version.
The problem with user repos vs the AUR is that you're trusting the maintainer behind them instead of inspecting the PKGBUILD and fetched sources yourself.
ptx 11 hours ago [-]
What do you mean? Their package manager allows you to add additional repositories, if that's what you want.
yjftsjthsd-h 11 hours ago [-]
How is that different?
ameliaquining 15 hours ago [-]
Yeah, the security problems with unilateral adoption of orphaned packages by unprivileged users are fundamental and unfixable; the only remedy is to remove the feature. Whether it has legitimate use cases (which it sounds like it does) is irrelevant. I'm not sure why it took them so long to realize this and act accordingly, but I'm glad they now have.
uticus 15 hours ago [-]
From the actual announcement:
> ...package adoption is currently disabled while
we are handling the situation.
Sounds much more like the temporary pause, than the much less temporary-sounding "has been disabled" from the OP.
pessimizer 14 hours ago [-]
Sounds like it has been disabled, which is exactly what was said.
uticus 15 hours ago [-]
WRT package vulns, I'm surprised there's not more technical theory out there. We have plenty of theory around algorithm design, but so far I haven't heard much about inspecting and improving control of dependencies in source - apart from conflict and version management.
Seems like instead of big-O notation, we could have a "reach index" - how far does the top-level code need to reach, to be effective? Top-level -> Userland lib 1 -> Userland lib 2 -> Kernel, would be a reach level "4" - not the simplest, but much simpler to inspect and securely build than reach level "20".
zache6 15 hours ago [-]
I haven't been updating AUR packages since the initial incident. Thankfully hadn't updated for a week prior to it. Tonight I'll be uninstalling all the AUR packages I possibly can.
catuscubitus 12 hours ago [-]
> I haven't been updating AUR packages since the initial incident.
The world of exploits and malware thanks you for your service.
> Thankfully hadn't updated for a week prior to it.
Chances are this started more than a week before it was discovered.
> Tonight I'll be uninstalling all the AUR packages I possibly can.
Instead, you could just use the AUR mindfully in terms of which packages you install and review the code.
tim-projects 15 hours ago [-]
I added a git repo to AUR last year. It was super easy with basically no checks of any kind. Once these reports came out recently, I went through and deleted every AUR package that I could.
antibarbarus 14 hours ago [-]
Ever since the first wave of attacks it was clear this wasn’t a passing thing, and would return unless the AUR fundamentally changed. They introduced... email verification, then hoped for the best. In a sense it’s good that this has happened as I think it will help the team understand it can’t go on like this.
I’d hate to see an AUR that’s a walled garden, and I’m not sure what an Arch without the AUR would look like. But something in between will need to be invented.
weinzierl 13 hours ago [-]
The other favourite besides Arch is NixOS. How does it compare when it comes to supply chain security?
11 hours ago [-]
15 hours ago [-]
dandersch 15 hours ago [-]
I think Arch has to rethink what the AUR really is for in the age of AI.
If users aren't supposed to trust anything from the AUR, then they will start to use LLMs to scan PKGBUILDs for them. But at that point, why not let the LLM loose directly on the upstream repo and build+install the package from source?
nvme0n1p1 15 hours ago [-]
You really don't see the difference between a deterministic script installing a tarball pinned by its hash, and "sudo chatgpt install master branch of this repo"?
warkdarrior 14 hours ago [-]
Yes, the second option gives me an easily inspectable list of results (as I can see all the tool calls the model made). The deterministic script is probably overly complex and hard to read, maybe supports ten billion platform combinations.
rcxdude 14 hours ago [-]
Most PKGBUILDS are stupidly simple, they're probably easier to read than a set of tool calls. See this for a randomly picked recently updated example:
(honestly I think the way that arch packages work is really nice compared to most other distros: you can almost copy and paste the README of a project into one and have a package)
Here's the most complicated one I found, building a browser:
The main risk, if you're reading them, is typosquatting and hiding the malicious code in what the project downloads.
Matl 14 hours ago [-]
Arch is famously x64 only?
tyfon 14 hours ago [-]
I run it on my milk-v duo s risk sbc. The risk-v version is maintained by a few dedicated people, and the milk-v specifics I had to fix myself. But it works :)
Matl 14 hours ago [-]
I knew there's an unofficial version for ARM. I meant more that the vast majority of AUR packages target x64 only because that's what 'official' Arch supports.
That being said, didn't know there's a RISC V effort as well now, so TIL.
ethin 14 hours ago [-]
> The deterministic script is probably overly complex and hard to read, maybe supports ten billion platform combinations.
Uh sorry what? Can you point to a PKGBUILD that is indeed this complex?
dlcarrier 13 hours ago [-]
The AUR is still a better option than using curl to freebase shell scripts straight from github, which is pretty much the go-to route for any LLM-generated guides.
Or you could use Nix as a package manager on practically any distro or OS of your choice. Arch, Debian, Windows, macOS - it doesn't matter. Most users should never ever need to bother with AUR again with this approach.
Nobody needs to rethink anything in "the age of AI". Stop trying to make everything about your favorite topic. If the tool can provide value then they'll use it, if not they won't.
Sleaker 15 hours ago [-]
I don't think any form of automated adoption of orphaned packages will ever work, it's just too easy to introduce malicious code into an otherwise functional but no longer maintained source.
charcircuit 15 hours ago [-]
AUR should be scanning new uploads for malware before allowing them to be published.
gh02t 14 hours ago [-]
A complication is that AUR doesn't publish packages, it's more like FreeBSD ports in that they are the build scripts for packages and the user builds the package on their local machine. Building an AUR PKGBUILD inherently runs arbitrary code on the user machine, and that code is controlled by the maintainer of the AUR package.
So you have to scan an arbitrary bash script and determine if it pulls malware, or build the package server side in a sandbox and scan it (and some AUR scripts wrap proprietary software blobs the user is supposed to provide e.g. MATLAB, which makes those impossible to build server side). It's a very big extra layer that malware deployments can hide in.
cube00 14 hours ago [-]
You can only scan for known malware. Plenty of ways to write new apps to do bad things that scanners won't detect.
charcircuit 12 hours ago [-]
Just because it's impossible to catch 100% that doesn't mean it is not worth doing.
kingwill101 10 hours ago [-]
You really only upload a manifest and probably a few scripts. Most often AUR packages are just calling out to download external binaries etc
tempfile 15 hours ago [-]
What does "scanning for malware" mean? As far as I know this is a totally open question, and the only credible answers (install in a sandbox) are too inconvenient for widespread adoption.
charcircuit 12 hours ago [-]
>are too inconvenient for widespread adoption.
The owners of AUR would do this for all packages they host so the inconvenience does not fall on other people. AUR has to take responsibility over the security of what they offer.
shevy-java 14 hours ago [-]
AI is killing linux distributions now. This is another example.
einsteinx2 14 hours ago [-]
This kind of hyperbole isn’t helpful.
Security concerns about supply chain attacks in the AUR (well known to be extremely insecure well before LLMs got popular) isn’t “killing” Arch let alone “killing Linux distributions”, plural.
nobody42 14 hours ago [-]
It's just entropy.
Favorable environment of Linux distros is an initial phase of technology. This state is gone for years now, AI is just making it evident. Adapt or become obsolete.
stock_toaster 14 hours ago [-]
Maybe just poorly run ones?
bionade24 14 hours ago [-]
Flatpak, Snap Store & PPA malware has been a thing for a long time already.
simonask 14 hours ago [-]
The older I get, the more critical I become of the culture of anonymity in OSS.
The obvious-but-hard solution to this, as well as certain other attacks like the xz incident, is a chain of trust. Every line of code in every package should be cryptographically attributable to an individual or an organization, ideally associated with a government-issued ID. Git commits without a real name and a cryptographic signature should be taboo. Nobody should be running or distributing software that they don't know who made.
It wouldn't be perfect - Russia could still attack the AUR, for whatever reason - but the current situation is extremely laissez-faire to the point of being untenable.
Every time Apple's App Store policies come up, it gets criticized by hackers for various good and bad reasons, but this is exactly the problem they're trying to solve, however imperfectly.
In Open Source, we're quite focused on copyright: the concern that someone's honest work gets stolen or appropriated without whatever recognition, attribution or compensation is laid out in the license. But this is the reverse problem: Lack of attribution, and therefore traceability.
So what would that take? What would we lose?
slowin 14 hours ago [-]
> What would we lose?
You'd lose the ability to work on and distribute software not approved by your and various other governments. For example, if the UK makes BitTorrent illegal, what happens to you when you've attached your identity to your torrent client when you try to enter the UK (or already live there)?
Security must be solved without removing anonymity.
gustavus 14 hours ago [-]
I love how people blame anonymity for the current internet problems. Whereas when anonymith was the default we had almost none of the problems.
Most of the problems seemed to have started once anonymity stopped being the order of the data, and things like Facebook and Twitter became big where everyone's real identities became tied to their online behavior.
It’s a different world now. I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
This has absolutely not ever been the case.
EDIT: Rereading, maybe it's that other kind of "hacker"...
If 1:10,000 people is an axe murderer, when your community reaches 20,000 people... You have to create an axe-murderer-captcha.
I think it was. Eg: on most russian warez forums in the 2000s, it was a bannable offense to crack russian-authored software.
That being said, I think the particular example you provided is kind of weak. It's my understanding that the behavior you speak of was driven primarily by the Russian government's unofficial policy of ignoring cybercrimes committed by their citizens so long as the targets were not domestic. They were ensuring their ability to continue operation by banning discussion of targeting Russians. This is how groups like the Russian Business Network have been able to flourish.
What’s more likely is the effort required for large scale attacks is easier now than ever thanks to LLMs.
My assumption is these aren't so much hackers, as modern day script kiddies armed with LLMs and too much free time.
There have been a variety of cultural elements to people doing security research / hacking on their own systems / etc.
There has never been "honor" among criminals looking to use technology to steal money or steal things that can be converted to money.
I also believe this is the main reason why web took off: effortless distribution and sandboxing.
It's weird that installing software is weird to you.
The answer is: Russians
Source: I'm the guy that built the antimiasma mitigation tool [1] and tracked their malware campaign iterations very closely.
Set LANG to ru_RU.* and the malware implant stops spreading itself, as with all APT28/29 malware.
[1] https://github.com/cookiengineer/antimiasma
[2] https://cookie.engineer/projects/cyber-defense/antimiasma.ht...
Now it got more popular but still low entry attack.
> It’s a different world now. I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
Not sure why hacker would waste their time fiddling with Arch instead of hacking stuff, everything that they need can run just fine on any of the Debian derivatives.
That is never how the AUR was supposed to work. Updates were intended to be a manual process where the user reviewed changes to the PKGBUILD.
And no, "people using one Linux distro can opt in to possibly getting pwned by each other by making use of a third-party software depot" does not reflect upon the entirety of the Linux world.
And unfortunately that’s how arch is mainly marketed by its users. “Arch has the latest everything, if it’s not in the repos it’s on AUR” is one of the standard selling points.
Of course that speaks to how people use linux insecurely not how Linux is insecure.
Maybe most users just ignore that and always answer yes without inspecting it. I don't know. But the wiki for the AUR and Readmes for many of these tools have warning banners telling you not to blindly trust AUR packages.
There are more ways to attack people than third party software depos.
significantly so. Windows has a coherent story when it comes to permissions and access. Differentiated out access controls, least privilege, UAC, mandatory integrity control and all configured out of the box.
Without AppArmor or SElinux correctly configured, which it isn't on most desktop distributions in the linux world most of your apps can still read anything, there's little sandboxing. The NT Kernel was designed with an object model in mind so you always had the abilities to have rich descriptions and policies for whatever you're handling where all of that is bolted on unix systems after the fact.
Yet that doesn't seem to matter much for stealer malware.
Of course Windows regardless has taken the brunt of the attacks because it ran virtually every desktop machine in the world so people go after users anyway. Desktop Linux systems where never economically interesting for malware. But now that they have gained a modicum of traction they're going to get the exact same treatment, hence this thread.
Microsoft doesn't advertise it much but they do have the advantage of controlling their build environments, software is signed etc. A system like the AUR where you pull in unsigned packages from anonymous people with so many arch users relying on it is not going to be easy to address. It lived on security through obscurity.
It's not meaningfully reduced. The stealer just has to call CryptUnprotectData before uploading it. It's not even like it will show a suspicious prompt to the user, without having to do anything extra the stealer can silently decrypt it.
I agree with the rest of the post though.
It's definitely an outlier, but more in terms of being something that doesn't really exist anywhere else, so of course the security model for it will also be an outlier. That's not an excuse for any security issues, but it's not like Arch doesn't have official repos with maintainers who are just as diligent as any other distro. They just also happen to provide a public git server that people can publish packages to with a UI for seeing some of the package metadata; people could just as easily write toolling to automate package management where it looks for a GitHub repo instead of an AUR one to fetch the build files.
I use FresBSD, where I rarely run in to this problem, that something is missing from ports.
However, it is a common occurrence in Arch. Which is a shame, because it’s otherwise a fine operating system.
Disabling AUR package adoptions has been like the #1 thing recommended. While it's a positive step, it's not good news they literally tried everything else first. This doesn't speak well to the security headspace of the Arch maintainers.
Yes, lots of people thought disabling package adoption is/was a good idea. It seems quite likely that the Arch DevOps team also could have come up with that one, and they certainly wouldn't have missed all of the people telling them to do so.
It seems to me that disabling package adoption is not a desirable thing to do in general, and can only be used as a stopgap response to an emergency, which seems to be what is happening right now.
"just disable adoption" certainly can't be a long-term solution: Without adoption, the AUR will slowly fade away as orphaning a package would be permanent. Maybe the idea is to have some sort of approval process to filter adoption requests? In that case the AUR just dies instantly as that would effectively be another official repo with all of the issues that that would bring.
This - they tried this first even though it’s pretty obvious this is an ineffective mechanism to fight security issues around adopting orphaned packages.
“Security headspace” means treating security seriously and acting appropriately and correctly with appropriate urgency. This whole saga they were slow to respond, they took days to actually stop the ongoing attack, and have tried everything else other than stopping adoption of orphaned packages. This should have been the FIRST thing done and only once you have a solid idea on how to reenable then you allow it. And even then I’m not sure orphaned packages are ever suitable for adoption - if you want to take over for an abandoned project, you start your own alias and try to convince all downstream dependencies to change where they point. This makes it adoption by the community which is slow and takes time and won’t be as trivial to convert into a mass scale cyber attack.
That everyone here is “but adoption is required for AUR” makes it clear there’s very limited experience and research on how other package managers don’t have this embarrassing failure (both OS and language ones like node and Cargo which have to deal with far more sophisticated attacks) and this is the way - you don’t allow identity laundering. They are all susceptible to identity laundering by just buying the project (assuming the maintainer is open to selling their keys) but that’s harder to scale by a script kiddie and requires a more sophisticated form of action.
Fedora Copr, FreeBSD Ports, are all of a similar idea. Where Arch screws up is in allowing people to take over abandoned PKGBUILDS instead of making them create new ones.
This can happen to Ubuntu with the PPA's too if someone were to gain control over, say, the Nvidia PPA for drivers. It's happening almost daily with NPM and Github. Supply chain attacks are serious and the Arch devs do warn people about this right off the bat. You don't go installing from the AUR without understanding the risks.
1. Lose money burning tokens in all of this stuff. 2. Lose reputation when some malware eventually makes it through
Do you have a solution to ever reenabling package adoptions? It's pretty much a must have feature for this to exist long term, at least in the AUR's current state where its a repo your not supposed to auto install from but pretty much all users do.
Really disabling adoptions is probably step 1 to just EOLing the whole thing.
The AUR by definition isn't to be trusted. That's what the official repos are for, you're supposed to read what the package install scripts are doing.
If you want to convince someone “my copy of foo is much better maintained than foo-legacy” you are free to go downstream dependency by downstream dependency and convincing a switch / convincing end users to install yours. You can even have hints to users “hey this package looks to be abandoned - did you mean X”
That's what they should do. The AUR has been a giant fuckup since the beginning, which is especially outrageous seeing as they had the perfect template for it with Gentoo's GURU.
I assumed the goal was to reduce usage of AUR, they've actually remove the ability to adopt (take ownership of) orphaned packages. I'm sure there are legitimate uses of that functionality, but it also seems like a pretty big avenue for abuse.
Which is probably the best choice, unfortunately.
To avoid package name pollution, e.g. having package foo, foo-newpackage, foo-newpackage-updated, etc. each by a new maintainer as the priors get abandoned.
https://wiki.archlinux.org/title/Unofficial_user_repositorie...
The problem with user repos vs the AUR is that you're trusting the maintainer behind them instead of inspecting the PKGBUILD and fetched sources yourself.
> ...package adoption is currently disabled while we are handling the situation.
Sounds much more like the temporary pause, than the much less temporary-sounding "has been disabled" from the OP.
Seems like instead of big-O notation, we could have a "reach index" - how far does the top-level code need to reach, to be effective? Top-level -> Userland lib 1 -> Userland lib 2 -> Kernel, would be a reach level "4" - not the simplest, but much simpler to inspect and securely build than reach level "20".
The world of exploits and malware thanks you for your service.
> Thankfully hadn't updated for a week prior to it.
Chances are this started more than a week before it was discovered.
> Tonight I'll be uninstalling all the AUR packages I possibly can.
Instead, you could just use the AUR mindfully in terms of which packages you install and review the code.
I’d hate to see an AUR that’s a walled garden, and I’m not sure what an Arch without the AUR would look like. But something in between will need to be invented.
If users aren't supposed to trust anything from the AUR, then they will start to use LLMs to scan PKGBUILDs for them. But at that point, why not let the LLM loose directly on the upstream repo and build+install the package from source?
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=batte...
(honestly I think the way that arch packages work is really nice compared to most other distros: you can almost copy and paste the README of a project into one and have a package)
Here's the most complicated one I found, building a browser:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=flowf...
The main risk, if you're reading them, is typosquatting and hiding the malicious code in what the project downloads.
That being said, didn't know there's a RISC V effort as well now, so TIL.
Uh sorry what? Can you point to a PKGBUILD that is indeed this complex?
See also, the -o- emoticon: https://youtu.be/M1si1y5lvkk&t=1902s
https://repology.org/repositories/graphs
So you have to scan an arbitrary bash script and determine if it pulls malware, or build the package server side in a sandbox and scan it (and some AUR scripts wrap proprietary software blobs the user is supposed to provide e.g. MATLAB, which makes those impossible to build server side). It's a very big extra layer that malware deployments can hide in.
The owners of AUR would do this for all packages they host so the inconvenience does not fall on other people. AUR has to take responsibility over the security of what they offer.
Security concerns about supply chain attacks in the AUR (well known to be extremely insecure well before LLMs got popular) isn’t “killing” Arch let alone “killing Linux distributions”, plural.
Favorable environment of Linux distros is an initial phase of technology. This state is gone for years now, AI is just making it evident. Adapt or become obsolete.
The obvious-but-hard solution to this, as well as certain other attacks like the xz incident, is a chain of trust. Every line of code in every package should be cryptographically attributable to an individual or an organization, ideally associated with a government-issued ID. Git commits without a real name and a cryptographic signature should be taboo. Nobody should be running or distributing software that they don't know who made.
It wouldn't be perfect - Russia could still attack the AUR, for whatever reason - but the current situation is extremely laissez-faire to the point of being untenable.
Every time Apple's App Store policies come up, it gets criticized by hackers for various good and bad reasons, but this is exactly the problem they're trying to solve, however imperfectly.
In Open Source, we're quite focused on copyright: the concern that someone's honest work gets stolen or appropriated without whatever recognition, attribution or compensation is laid out in the license. But this is the reverse problem: Lack of attribution, and therefore traceability.
So what would that take? What would we lose?
You'd lose the ability to work on and distribute software not approved by your and various other governments. For example, if the UK makes BitTorrent illegal, what happens to you when you've attached your identity to your torrent client when you try to enter the UK (or already live there)?
Security must be solved without removing anonymity.