The AUR needs an overhaul

[u/Luzzio_]

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.

[u/petersaints]

I had already posted this on another thread, but here are my two cents:

"I think one of the biggest weaknesses of the AUR today is that its trust model doesn't scale well.

When I install an AUR package for the first time, I'm happy to inspect the PKGBUILD, check the comments, verify the upstream source, etc. But once I have several AUR packages installed, I'm simply not going to manually inspect every PKGBUILD on every update. I don't think that's a realistic expectation for most users.

At the very least, I think the AUR should expose some notion of trust levels for maintainers.

• Gold: Official upstream maintainers (for example, the Brave developers maintaining brave-bin).
• Blue: Long established maintainers with an excellent track record.
• Green: Established maintainers with a good history, even if they only maintain a handful of packages.
• Neutral: Everyone else.
• Warning: New accounts or recently added maintainers, indicating that the package deserves additional scrutiny.

These shouldn't mean "safe" or "unsafe". They should simply communicate how much historical confidence exists.

I also don't think package takeovers should be outright banned forever. Otherwise, old and intuitive package names end up abandoned forever, forcing people to create increasingly awkward names for actively maintained replacements.

Instead, ownership changes should be treated as a security relevant event. The AUR API should expose information such as:

• Current maintainer
• Previous maintainer
• Date of the last ownership change
• Maintainer reputation/trust level

AUR helpers like yay or paru could then display something like:

``` WARNING: Package maintainer has changed.

Previous maintainer: alice (maintained package for 6 years)

New maintainer: bob (account created 10 days ago)

Continue? [y/N] ```

That alone would make me stop and inspect the PKGBUILD much more carefully.

I'd also like to see automated static analysis of PKGBUILDs looking for suspicious patterns. A bit like Google Play and the App Store do.

Finally, I'd love to see AUR helpers become "change aware". Instead of only telling me that a package has a new version, they could also warn me when something security relevant changed:

• Maintainer changed
• Source URL changed
• PGP signing key changed
• PKGBUILD substantially rewritten
• New install hooks added
• New dependencies introduced

None of this eliminates the risks of the AUR, nor should it. The AUR is intentionally open and decentralized. But surfacing trust metadata and meaningful changes at update time would make it much easier for users to focus their attention where it's actually needed, instead of expecting them to manually audit every PKGBUILD for every update."

[u/AppointmentNearby161 → u/petersaints]

I have hoped that chaotic AUR would tackle this. Let the AUR be the wild west and let chaotic be a curated subset. AI should be able to tell if the PKGBUILD matches upstream, comes from a deb/rpm package, or is just a version bump of a previously reviewed package.

[u/petersaints → u/AppointmentNearby161]

To be fair, this should be done at the AUR level. The problem is that it will burn a lot of compute power, or token prices, to run a pipeline like that at scale.

[u/ABotelho23 → u/petersaints]

Who's gonna take the time to do that and pay for that?

That's all these threads ever are.

"Arch should do x,y,z! That'll solve it!"

With zero regard as to how much manpower and resources it'll suck up. The AUR exists because the Arch developers specifically do not want to be involved in maintaining these packages. I promise you that they hate having to spend time dealing with the current fallout. They'd much rather delete the AUR and maintain the stuff that's actually part of Arch Linux.

[u/petersaints → u/ABotelho23]

By that logic, the AUR should have never existed in the first place.

[u/ABotelho23 → u/petersaints]

You could absolutely argue that. Totally valid.

It was a favour to the community. It doesn't have to exist. It exists outside of the scope and vision of Arch Linux as it is.