[animitronix]

Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.

[jorams]

> Guess I'll be switching to a new OS this weekend across multiple machines.

This is a bit of an odd response. Arch very explicitly separates the AUR from everything else and doesn't make it easy to work with, because its security model has always been fundamentally broken and requires you to do your own vetting. It exists to facilitate sharing of package recipes between untrusted users. You should treat it like a pastebin.

[simoncion]

> ...because its security model has always been fundamentally broken...

I disagree that "These packages are provided as-is. No work has been done to determine their safety or fitness for purpose. Use at your own risk!" is a "fundamentally broken" security model. It's one that places the burden of verification and validation on the system administrator and -in the case of the AUR- fully informs them of this fact. Treating system operators like the adults that they are isn't "fundamentally broken", but it is _much_ more work for that operator than if they relied exclusively on distro-vetted packages.

I do agree that it'd be fucking silly of OP to switch away from Arch because some of the packages in the collection of packages that are explicitly provided as "as-is and unvetted" got some malware in them.

[Hackbraten]

I agree. If you use the AUR, you're essentially no longer running Arch Linux but your own private fork of Arch Linux.

[mqus]

Tbh Arch itself is the most explicit about this compared to the derivatives. Manjaro etc allow installing AUR stuff directly from their main package manager

[rossvor]

Nothing here is "fundamentally broken". Any usage of AUR was always one step above executing random shell scripts from the net, and any official Archlinux guides were explicit about it. That's why there are no AUR helper tools in official repos and their usage was always discouraged in forums/wiki.

PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and review before running executable files you download from the net. Common sense stuff. That's always been the trade-off and it hasn't really changed much in last 20 years (even though every few years everyone seems to freak out over it).

[lordleft]

You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)

[noirscape]

To be fair, the advice very rarely is for people to jump onto Arch based distros.

The problem is more that the Arch value proposition kinda presupposes the sort of user that's going to "feel superior" about having it installed[0]. It leads to people that have no business installing Arch Linux (as it doesn't match their usecase) installing Arch Linux because it makes them feel cool.

I don't have a good answer for this, besides making it more apparent what people should expect from having Arch installed. My recommendation usually goes something like this:

* Do you want to have the latest version of all software, regardless of the question if it's well-tested beforehand?

* Do you want to have all software distributed in an as-close-to-upstream approach as possible? Be aware that "upstream" configuration can sometimes significantly differ from defaults most people expect. (Sometimes there's reasons for this, sometimes upstream are a bunch of obstinate jerks.)

* Are you comfortable with a terminal?

* Are you comfortable with needing to suddenly learn how to troubleshoot a broken system after a routine update?

Only if the answer to all of those is "yes", then Arch is suitable for you.

And finally, more specific to servers, where the answer should be "no" if you want to use arch:

* Do you have the expectation to never have to touch the OS after it's been configured correctly besides routine maintenance (ie. installing security updates) and maybe a big update twice a year?

I used to use Arch, before realizing that my system was gradually morphing into a bespoke mess that didn't really serve my needs and that while doing something very specific was possible, I also had to configure a bunch of mundane stuff you aren't normally required to think about - there's never a "just install, activate and adjust as needed" with Arch. All I actually wanted was a distro with more recent software than "3 years old" (Debian/Ubuntu's sluggish package inclusion is not really useful for desktops).

So I looked around and realized Fedora worked better for me: professional, clean, recent software (every 9 months updates, feature freezes are smart enough to account for ie. New Python releases) and not prone to sudden surprises.

[0]: https://wiki.archlinux.org/title/Arch_Linux is a good example of it.

[flomo]

To be honest, it took me way too long to figure the Arch etc crowd are hobbyists who enjoy having something which always 'needs maintenance' over the weekend. (And maybe they don't want to admit they are hobbyists because what they are doing seems Very Important.)

Sorta like 'car guys' who recommend some old thing you can wrench on.

[rossvor]

For what it is worth, while I'm sure it is right on target for some, I think that's incorrect model of a mean arch user. Updates are once a month thing for me (and the maintenance for that rarely exceeds 10m if that). I barely do any distro level tinkering, after all, I need to spare some time to improve my emacs config ;).

Basically, my model of a mean arch user would be closer to a DIYer -- likes to follow clear manual instructions, likes sturdy and non-ephemeral things, likes to know what the sausage is made of, but prefers if maintenance costs are minimized (since they will be bearing those costs and are responsible for the thing), so makes choices according to that.

[flomo]

Hey, your response improves my opinion of 'car guys'. Because the analogy is thin and they are looking directly at what is coming out of the 'sausage machine'. And if the result is good, they could sell the machine for profits! (Unlike computer nerds.)

I'm sticking with "hobbyists/dabblers" here, because almost nobody runs Arch in real production scenarios. Its just a fun high-touch thing people can enjoy fucking around with. Nothing wrong with that.

(That is why someone could trivially trojan hundreds of packages and it's NBD. Because "Nobody Cares." Wipe it and start over, funguy.)

[bachmeier]

Honestly, it's hard to see how Arch is a usable distro for most potential users without AUR. If you want a large selection of official packages, the Debian world is going to be the better choice.

[rossvor]

Obviously usages vary greatly, but I doubt it's that of big deal for majority of Arch users (maybe it's different for Arch derived distros). My AUR maintained package count has been in single digits for decades (both on my home PC and work station), and I don't think it as a heavy burden to update those packages. There's a certain selection bias going on here -- I drop AUR packages if they become too annoying (if they require updates too frequently or they want a slew of other AUR only packages as dependencies), I either find alternatives or alternative sources for them (e.g. flathub).

Arch still hits the sweet spot for me -- unobtrusive, close to upstream, and well-documented enough to keep full control over your own system. Both for the times when you want to go with the most default path and for the cases when you want to deviate and go play in the weeds.

[bachmeier]

I think the issue with AUR is that you get your foot in the door with packages like spotify[1]. It does its magic to allow you to install a .deb package on your distro. I don't know how else to install the Spotify desktop app without AUR. But once you're willing to do that, why not go a little further and trust other packages?

Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=spoti...

[rossvor]

I don't have it installed, so I can't comment if it requires constant babysitting, but looks pretty okay to me -- it has no AUR-only dependencies (++), one extra shell script (--), popular (++ given enough eyeballs...). Should be fairly easy to review, anything fishy should be fairly visible in git diff. If I needed it I would be using this PKGBUILD. It's a net gain that it exists there, someone else done most of the work for me.

> Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.

I mean yeah, but everything is trade off of volunteer + user attention. There is no trusted user™ who uses spotify, so it's not in official packages. So you as user need to maintain it yourself or rely on AUR and verify.

[megous]

It's about as much an end of AUR, as we've seen an end of npm from its many decades of similar security/trust failures.