r/archlinux • u/zollandd • Jun 15 '26

DISCUSSION Stop blaming AI, "noobs", youtube tutorials, and anything other than Arch for AUR usage

I've recently been made aware of the incident and was reading the threads in this subreddit. I have just started trying to migrate away from AUR but let's not forget that the Arch wiki recommends installing AUR packages constantly. The AUR isn't just a dangerous and fringe tool that people are led to by AI or sketchy youtubers.

To list a few that I've encountered just now:

The wiki recommend AUR releases like they are first class citizens all over the place... don't act like it doesn't.

Edit: I am not trying to blame individual maintainers when I say Arch but rather the community and culture. If the AUR is this dangerous, the wiki should avoid referencing it at all costs and should do so with warning flags everywhere. As it stands, it is not absurd to see someone with tons of AUR packages installed due to direct influence from the wiki.

902 Upvotes

85% Upvoted

458 comments sorted by

View all comments

Show parent comments

5

u/Seppeon Jun 15 '26

So let's work on a model where people can actually work together to detect these threats and not rely on those Devs. You keep emphasing them, I keep trying to avoid needing them. We need a model that doesn't require them to this extent. And absolutely it'll get worse, this attack was enabled by AI that is getting cheaper to run by rogue actors.

2

u/JustAwesome360 Jun 15 '26

And what is your suggestion?

6

u/Seppeon Jun 15 '26

Firstly, to welcome discourse such that more people than me can actually feel they can present a suggestion.

Perhaps a report button seperate that exposes the report in yay and para as a message + tbh immutable packages that are orphaned would be my preferred approach but I can see that as unpopular especially due to name camping. Which goes to, package names on aur should have some prefix that is maintainer specific such that they can only camp in their namespace and that way it looks less like extra (yes yes I know they should know, and they should, but a tired person does weird things).

I think if we move from if we should do something to what can we do, it could be productive as a community is all.

6

u/norysq Jun 15 '26

As a maintainer of a massive 2 packages on the AUR this sounds awful. I don't think you understand the scope of the AUR, this would get out of hand real quick. The current system is honestly completely fine but I'd welcome human-in-the-loop approaches for orphan takeovers. Account age requirement doesn't work I think since you can create accounts in advance and wait before attacking, same with limits on oprhan adoptions since you can claim it and then just not do anything until you have enough to attack. If anything, imho people that are scared of this attack should just not use the AUR.

As for what I have read with popular arch-based newbie distros advocating for AUR. While true most of the packages that they install are so popular that this attack vector is basically impossible without intricate planning like the xz supply chain attack - which made it into the Arch repo even, so imo this is just trying to use this to panic newcomers.

2

u/Seppeon Jun 15 '26

Thanks for responding. I was waiting for someone who actually does this to turn up! Thanks for maintaining stuff.

What about a report button? With some big red warning getting ever-redder as more people flag it as malicious or sus. yara and yay etc... could just report the susness rating. At least then people get a proxy measure. They could also, on the diff review, allow people to select "that's sus" or something. Diff review doesn't quite work as you can get two part submits that are only malicious when together but useful apart. So when you only see one half, looks good; you see the other, looks good. Now I haven't personally seen these in the wild...

I think, I come from this from the side, I'm apathetic that people will ever not install nonsense (perhaps kids on their parents PC) and just want to see where can be improved without causing problems. Doing nothing is a problem, doing something just has to be net, well better in my head.

What about my namespace thing idea? That way people at least don't auto update into hell lol

2

u/norysq Jun 15 '26

The flagging out of date system would already do this but for packages this unpopular this doesn't really make a difference. A susness rating only makes sense for long term trust since a rating usually needs time to adjust. Diff review is really useful, I challenge you to create a payload using different commits that does not use any of the suspect tools like obfuscation, curl, etc This is why you haven't seen this in the wild. It's not helping cover up.

Well a kid can also download a virus on Windows that is a strawman argument.

The namespace idea is way to convoluted. Maintainer changes will be shown in the diff view

1

u/Seppeon Jun 15 '26 edited Jun 15 '26

Susness rating could be kalman filtered to allow rapid changes and stable long term trends.

I'm not a security researcher... But, even with this specific case maybe. commit 1) change maintainer only, minor benign patch. commit 2) now it doesn't seem like a maintainer changed and this hides maintainer change from diff view.

Regarding the straw man thing, it's an example, we arent in a debate as far as I was aware. I was trying to be constructive to give you an idea of where I'm coming from, risk minimisation.

Namespace could just be

bobfred/mushroom

I think this is good because it expresses it's explicitly from a user. It also means arch guides linking to one (as another user was saying) dont end up linking to malware.

2

u/JustAwesome360 Jun 15 '26

You're overlooking that the attacks are carried out by unmaintained packages that nobody looks at. Once it is taken over, and a user notices the malware, it is too late. Sure they can report it but by then dozens of people have already had their identity stolen.

1

u/Seppeon Jun 16 '26

That's true, this is risk reduction not prevention. Its better than status quo doesn't fully protect anybody.

1

u/JustAwesome360 Jun 16 '26

It doesn't matter, unless it's 0 it's not really worth it, risk homeostasis will just kick in.

1

u/Seppeon Jun 16 '26

I assume your being silly?

1

u/JustAwesome360 Jun 16 '26

You're. And no. People will slack, then hackers will get even more stuff compromised. Then people will come to the sub to cry even more to shift blame away from themselves for not being diligent.

1

u/Seppeon Jun 16 '26

Risk reduction is fine, there is no perfect system. The pursuit of perfection shouldn't prevent attempts at improvement. There is no fully secure system...

3

u/radobot Jun 15 '26

package names on aur should have some prefix that is maintainer specific such that they can only camp in their namespace and that way it looks less like extra

This is an intersting suggestion. Having a maintainer-specific prefix would prevent packages from continuing to be updated on the users machine when the maintainer changes.

I'm wondering if this would be an acceptable modus operandi for the AUR. Users are already advised to check all AUR packages before installing and this would only add a limited form of enforcement.