[dbgobrrr]

> users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories.

I think this stance should be re-evaluated. Arch Linux developers are doing a fantastic job and I am personally thankful to them - this is not in any way critical of them. And while I don't see an easy solution here, I just feel that the time of "warning users" is long gone with how much supply-chain attacks are ramping up these days.

Some other controls could at least alleviate the problem. Perhaps some form of peer-review and grace period before publishing could help here?

[anon7000]

Idk. Arch does have official repositories that are actively maintained and vetted. AUR is for the vast amounts of random software that isn’t popular or important enough to be officially maintained.

I’m not sure how to find a balance. One reason to use Arch is to always have the latest software, especially if you’re gaming. (Need to run very recent kernels, GPU drivers, and DEs to support new graphics cards.) So that’s very different from other stable LTS distros which carefully pick the package updates they incorporate.

Anyways, I do agree package cooldowns and such make a lot of sense. Package managers should be pulling out the stops on all the free controls they can implement. I can understand why anything requiring compute or maintainer time is a non-starter. (Sidebar: I don’t feel the same way about npm. Microsoft can afford to run malware scanners and analysis tools on npm packages.)

https://wiki.archlinux.org/title/Official_repositories

[beej71]

There's some big stuff in AUR like the binary VS Code and Chrome, fwiw.

[drnick1]

I wouldn't those programs. You have the corresponding FOSS versions (code-oss and chromium) in the main repository. Chrome is basically spyware.

[newsoftheday]

I'm on Kubuntu and I install VS Code using Microsoft's repo and Chrome using Google's repo. Also I do Wine and Docker using their own repos. I can't imagine VS Code or even Chrome being put into the mainstream Kubuntu/Ubuntu repos nor why such a burden should ever be shifted to Canonical.

[vlovich123]

That’s because you’re using something those companies officially support. Is your argument everyone running Linux needs to be on a Debian-based or Fedora-based distribution?

Btw the official “vscode on Linux” instructions literally point to the community maintained AUR (same for nix).

The truth of the matter is the AUR is poorly maintained structurally, regardless of what companies officially support. Things like letting arbitrary people unilaterally take over orphaned packages is horrendously stupid.

[sam_lowry_]

Stupid or rather low-friction on purpose?

[vlovich123]

Stupidly low friction. Consistently failing to learn from the mistakes of package managers is bad enough. Failing to learn from your own is another level.

“Learning from your mistakes is good. Learning from the mistakes of others is better”.

For all its flaws, at least Cargo attempts to do that. AUR does not. No other package manager this regularly has hijacking problems.

[emsign]

Both. And that's an even worse combo, making stupidity frictionless.

[tjoff]

Since you are using the official repos thats not an issue. The issue is when the package creator is some rando on the internet.

[mcv]

It's definitely a sign that popular packages should be moved from AUR to the official repository. I've got some stuff from AUR simply because it's something I need and that's where it is, and I never really verify it's safe; I just trust it blindly. Clearly a bad idea. I guess I should learn to avoid AUR and when I do use something from it, we more aware it's an exception and I need to check it more thoroughly. That's something I normally only do only for stuff that's neither from AUR nor the official repo.

[axus]

How much work is created (and for who) when a package is moved to the official repository?

[homebrewer]

A package maintainer has to be interested and willing to support it. Sometimes packages get dropped from the official repositories into AUR when the maintainer loses interest, and noone else wants to pick up the slack.

[thewebguyd]

> Some other controls could at least alleviate the problem

The biggest one I'd suggest they change immediately is remove the ability for anyone to just take over an orphaned package. That's a crazy policy, to me.

It should require you to fork it & resubmit, not take over the original.

Then they can go through and do purges of orphaned packages that are beyond a certain age.

[xnzakg]

How would this help against someone submitting an actual, non-compromised version bump, then adding malware once it's accepted?

[embedding-shape]

Personally, what you suggest would defeat the purpose of the AUR, and what you describe is already applied to the official packages. If you want only the safe and stable stuff, don't use random packages from AUR :)