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?
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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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"?
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.
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.
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.
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.
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.
> 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.
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.
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.
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".
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.
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.
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?
> 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.
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"...
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.
Arch is simply getting popular enough to be targeted.
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.
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.
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.
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.
Castles made of sand slips into the sea, eventually
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.
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.
MS-Windows gets attacked by the hardware vendors, too.
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.
> 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.
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.
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?
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"?
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.
Arch is famously x64 only?
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.
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.
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.
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.
Problem is that there is no KYC process before someone can adopt any orphaned package
> 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.
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.
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.
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".
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.
Sounds like it has been disabled, which is exactly what was said.
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.
AUR should be scanning new uploads for malware before allowing them to be published.
You can only scan for known malware. Plenty of ways to write new apps to do bad things that scanners won't detect.
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.
AI is killing linux distributions now. This is another example.
Maybe just poorly run ones?