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.
What’s more likely is the effort required for large scale attacks is easier now than ever thanks to LLMs.
I also believe this is the main reason why web took off: effortless distribution and sandboxing.
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.
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.
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?
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.
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.
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.
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".
> ...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.
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.
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.
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.
Uh sorry what? Can you point to a PKGBUILD that is indeed this complex?
That being said, didn't know there's a RISC V effort as well now, so TIL.