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?

> 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.

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?

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.

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.

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.

AI is killing linux distributions now. This is another example.