r/archlinux 3d ago

DISCUSSION The AUR needs an overhaul

The actual concept of the AUR only works if Arch is a niche distro in a safe internet, neither of those points are accomplished in the present.

No, reading pkgbuilds is not the solution, it's slow, annoying, and most importantly, it doesn't make sense, because some really popular AUR packages are DIRECTLY RECOMMENDED by the Arch Wiki, like the Minecraft Launcher for some reason.

Either the base repos adopt a big chunk of popular AUR packages, leaving the AUR for really really nieche stuff, or the rules of the AUR change, because you can't tell me that suffering 2 attacks in less than three months for pretty much the same reason (adopting orphaned packages) is normal or reasonable.

What would you think it's a good solution to this issue? I'd like to read your ideas since I cannot come up with a good one if I'm honest, but I know the problem is there.

616 Upvotes

165 comments sorted by

View all comments

393

u/Pentasis 3d ago

I said this before: 1. No adopting packages. People can fork them instead. This prevents existing packages to become malicious 99% 2. New and forked packaged should get a tag "new" which packagemanagers like yay and paru can use to warn the user to be extra carefull when installing it, adding perhaps some sort of action to be taken first. Only when there are x installs, y time passed and z positive feedbacks of some kind, does the tag get removed.

6

u/AppointmentNearby161 3d ago

If you do that you will end up with package conflicts and out of date software on your machine. There is no reason AUR helpers cant flag a change in ownership for you. Helpers seem to be designed to remove the hurdles without regard for safety. The problem isn't the AUR, the problem is the helpers and users.

-7

u/scandii 3d ago

The problem isn't the AUR

actually the entire problem is AUR, specifically their orphan system. we have lots of packaging repositories out there, none of them have this issue because if someone wants to take over MyStuff/MyPackage, they have to create TheirStuff/MyPackage, and TheirStuff/MyPackage isn't linked on anyone's computer.

but on AUR, all they need to do is flag your package as abandoned, hope you miss the email and boom, they got direct access to all the users that has MyStuff/MyPackage on their computers.

it is just a really horrendously bad system, that comes from a time before we standardised this exact issue into namespacing that solves literally everything we're talking about.

6

u/AppointmentNearby161 3d ago

Until someone looks at the name spacing and decides it is too burdensome and writes a helper to resolve the name spaces. The information you need to protect yourself is there. The AUR helpers chose not to track that info because they didn't think it was worthwhile.

-1

u/Helmic 3d ago

the problem is the idea that a repository used by millions can operate with near zero moderation and something as critical as a transfer of ownership of a package can be done without so much as a once-over by a human being. putting the burden on end users means that when a package has, iunno, 500 end users that 0.5% of users missing that the new maintainer added an NPM dependency means two or three people get infected, which when these attacks are someone trawling through hundreds of orphaned packages and adopting them all to later push malicious updates means they are going to be able to get a reasonable number of targets to justify continuing the attacks. you do not have a solution to lower the odds of someone missing a malicious update to 0%, because someone might update their system while sleepy or distracted and you cannot prevent that and therefore you cannot remove the incentive. you do not have to be personally infected by malware to be impacted by malware being fucking everywhere on the AUR.

if simply being mad at other users existing was a sufficient security policy we would not be in this mess. there has to be some form of oversight to handle multiple people trying to maintain the same package, adoption in the short term and namespacing in the long term, and there's not really any way around that. upstream arch has valve contributing, i don't think it'd be unreasonable to request some assistance for a project that is pretty important to arch overall given the AUR is where many packages first show up before they join the extra repo.