Comment by vlovich123
5 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.
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.
> 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.
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.
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.
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.
>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.
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”
> 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.
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?