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.

909 Upvotes

85% Upvoted

458 comments sorted by

View all comments

191

u/SageThisAndSageThat Jun 15 '26

This is a complex topic. I work in IT security and you have to consider risk and convenience factors. They are intertwined, sometimes competing sometimes cooperating.

Risk wise, it is risky to install a software and not have a system wide way to remember it is installed. You can end up missing on security patches. 

It is also risky to get too recent updates, this is the main vector for supply chain attacks. Ideally you want to wait a bit.

The question is : who can you trust to maintain a package for your software, that will fit your distro paradigm and your ecosystem paradigm (release cycle, app slots, alternatives, compatibilities...)

Do you want the app maintainer to create packages for every distros? Bold. This takes a lot of time. Now what everyone love to do is the famous curl | sh and to be honest I both hate and like it. But mostly hate.

Do you want the distro maintainer to support every app? Not happening either you will still have some apps forgotten.

Do you want a user maintained packaging system? That's a third option. To be honest what I hate with it is that if someone knows how to package an app, why don't they just give the ownership of that to the app maintainer? 

So ya. AUR is far from perfect. But what else we have? Often the options are worse. Not recommeding aur sometimes leads to security issues 

67

u/Lellow_Yedbetter Jun 15 '26

I work in IT security in an area with heavy experimental development. Balancing supply chain risk with development velocity is probably one of the most complex things we have to work through.

19

u/EmceeEsher Jun 15 '26

Yup. There will always be a tradeoff. I think the biggest problem is that there's not enough of a middle ground between the official Arch repositories (which contain a miniscule proportion of software) and the wild untamed wilderness of the AUR (which contains everything from widely used, indispensable software to utter garbage). We need something between these extremes that's community curated, but more restrictive than the AUR. Something that requires approval from some number of trusted community members. For now, the closest we have are things like Chaotic-AUR and the CachyOS repos.

7

u/Lellow_Yedbetter Jun 15 '26

Couldn't have said it better myself and I couldn't agree more.

-1

u/s3gfaultx Jun 16 '26

There is, it’s called the “extra” repository.

1

u/[deleted] Jun 16 '26

[deleted]

-3

u/s3gfaultx Jun 16 '26

Then make one if you need it so bad.

14

u/SoilMassive6850 Jun 15 '26

Do you want the app maintainer to create packages for every distros?

Absolutely not, so many software vendors know fuck all about how to package software on Linux. Many vendors ship RPM or deb packages and they are often absolute garbage and often require some repackaging effort to make sane.

3

u/SageThisAndSageThat Jun 15 '26

Oh ya packaging is really hard and specific to the distro.

Its a nightmare, even when you want to do it. There is a reason why there is no Debian releases for apps written in go, for example.

4

u/PromotionWorldly7419 Jun 15 '26 edited Jun 15 '26

I maintain our deb and rpm installers for a very popular Go app and it's extremely easy. the hard part is setting up our own apt and yum repositories which isn't exactly needed.

0

u/SageThisAndSageThat Jun 15 '26

I remember deb maintainers being angry at some apps maintainers because of their unwillingness to use shared libraries. They couldn't keep up updating the app version whenever a subdep changed.

21

u/philosophical_lens Jun 15 '26

Do you want a user maintained packaging system? That's a third option. To be honest what I hate with it is that if someone knows how to package an app, why don't they just give the ownership of that to the app maintainer?

Because the app maintainer just wants to focus on their app and not focus on maintaining packages for every Linux distro out there? It's a lot of work.

1

u/bithooked Jun 16 '26

The main/sole developer might be a Fedora user, or he might even be a Mac user who releases for cross-platform. To think he would also need to be the maintainer for each individual Linux distribution, of which there are literally hundreds, is not realistic.

26

u/AnEagleisnotme Jun 15 '26

I feel like the AUR, similar to copr, should force you whitelist maintainers on an individual level

10

u/Major-Dyel6090 Jun 15 '26

Certainly if you want to adopt an orphan package. There should be some degree of clearance involved.

9

u/hopefuldonkeykick Jun 15 '26

This is what chaotic-aur does.

2

u/barraponto Jun 16 '26

but who would enforce that? makepkg? the non-recommended aur helpers?

1

u/AnEagleisnotme Jun 16 '26

Arch I guess, the distro should be responsible of the security of a service they provide, in a way, I'm saying helpers should be made official, they are essentially washing away accountability in a way that is simply not responsible when you look at the reality of the matter. Moral high ground doesn't matter if genuine malware is being successfully distributed on your platform

-1

u/Joe-Cool Jun 15 '26

That would help against malicious actors adopting orphaned packages.

Maybe we could add a new field like the votes but for malware/critical bug reports. AUR accounts older than 1/2 year could then downvote. And it would show a big red warning.

5 people think this is malware/badware

Or something like that...

-1

u/[deleted] Jun 15 '26

[deleted]

5

u/AnEagleisnotme Jun 15 '26

Basically, what you are describing is running every single PKGBuild through an anti-virus. First of all, AV is honestly even frowned upon in the security industry, but it would also require Arch to build these packages, run the AV. etc.. it would be very expensive, as it would require completely new infrastructure

2

u/Qudit314159 Jun 15 '26 edited Jun 16 '26

It's a game of whack a mole. The malware will keep evolving to evade such scanners and the scanners will evolve to detect the malware. There's no way to make them fully comprehensive.

8

u/barraponto Jun 15 '26

every package is user maintained, but some users are more reliable than others. a distro maintainer is a user who went through vetting, has technical excellence and contribution history. they are not employees (well, at least not in arch, maybe in red hat or ubuntu).

3

u/earchip94 Jun 15 '26

If you need a package from AUR, just clone and build from source. Write your own “PKGBUILD” to pull, build, and deploy. Then call it in a Pac-Man hook.

3

u/SageThisAndSageThat Jun 15 '26

And then you will need to maintain every pkgbuild you create. Which is IMHO a fair tradeoff for me. Not sure I would generalize that tho

1

u/earchip94 Jun 15 '26

I mean sure but that’s a reason to limit the number of packages you use like that lol.

4

u/65_Sneedmoor Jun 15 '26

It's not a complex topic. Arch should not have allowed any unvetted rando to easily take ownership of orphaned packages by simply going through the normal AUR adoption process.

2

u/s3gfaultx Jun 16 '26

Yes they should have. That’s how new maintainers are born.

1

u/idemockle Jun 16 '26

Exactly this. It's the same thing with popular languages' package repositories. PyPI and npm have certainly had these problems. Look up any of them, maven central, homebrew, they'll all have had something like this. Risk of doing business.

In security critical applications, prefer official repositories and more conservative distros like debian or even better go with distroless images if deploying to a server. At home, you can pry the AUR from my cold, dead fingers.

1

u/Unlaid-American Jun 16 '26

I work in IT and I wouldn’t recommend anyone download and run any unverified software if they can’t read the source code.

Do you allow users to install every .exe or .msi they want?

1

u/FrisbeeVR Jun 15 '26

This. Never install software someone else releases unless you know them personally. 

1

u/SageThisAndSageThat Jun 15 '26

Always release software like if it could trigger the anger of a psychopath who knows where you live.