Live data from Hacker News

Arch Linux disables AUR package adoption

lwn.net

91–100 of 133 posts

Re: Arch Linux disables AUR package adoption

#91
post #58

> 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 ad…

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 c…

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

Re: Arch Linux disables AUR package adoption

#92

> 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 ad…

>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 definitio…

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”

Re: Arch Linux disables AUR package adoption

#93
post #18

Earlier quoted context omitted.

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.

>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 sa…

>Windows has a coherent story when it comes to permissions and access.

Yet that doesn't seem to matter much for stealer malware.

Re: Arch Linux disables AUR package adoption

#94

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?

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. See also, the -o- emoticon: https://youtu.be/M1si1y5lvkk&t=1902s

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.

https://repology.org/repositories/graphs

Re: Arch Linux disables AUR package adoption

#95
post #75

Earlier quoted context omitted.

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

Or they just install it via random bash scripts on GitHub but that's just pushing the problem into the user.

Re: Arch Linux disables AUR package adoption

#96
post #11
post #7

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.

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.

Re: Arch Linux disables AUR package adoption

#97
post #76

Earlier quoted context omitted.

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.

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.

Perhaps, but it would be pretty unusual to use a commit/hash id instead of a version tag, or the main development branch.

Re: Arch Linux disables AUR package adoption

#98
post #11

Earlier quoted context omitted.

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

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

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.

Re: Arch Linux disables AUR package adoption

#99
post #7

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?

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.

Re: Arch Linux disables AUR package adoption

#100

> 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 ad…

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.

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

Post reply on HN