Arch Linux disables AUR package adoption
24 points by Levitating
24 points by Levitating
I have never used Arch, but I have maintained software that ended up in AUR. It always seemed a complete mess from the outside, often with multiple versions of the same package, sometimes unmaintained and obsolete. Arch-using people around me often mentioned the AUR as an advantage, but it seemed overly chaotic to me. What is the reason it ended up this way?
multiple versions of packages exist because everyone has a different needs i.e. one person wants to compile the latest release, another wants to download the pre-compiled release, someone else wants to compile the latest commit or a fork with a patch included, inevitably someone is gonna lose interest or a version is no longer relevant which is when the packages become unmaintained or marked obsolete allowing others to pick them back up if so desired.
Unlike similar projects like COPR or PPA there is only a global namespace in the AUR which makes it really annoying to deal with this sort of stuff
There's some historical writing about the repository developments and the AUR at https://wiki.archlinux.org/title/Official_repositories#Historical_background
The AUR in the end is a user repository, not a package repository like core and extra is, that's a double edged sword
That's a little disappointing, adoption avoids duplicating packages, this would just create otherwise redundant packages, but as long as it stops users from getting pwned...
DevOps team added some minor, and apparently ineffective, restrictions on creating new accounts.
The initial attack iirc was that you could adopt packages with only a SSH key required, so doing adoptions en-mass was very cheap.
Attackers do already know how to deal with email verification / disposable mail detection. In the end, it's about raising the floor required to pull off these attacks.
Wish the Arch Devops team lots of hugs
Here are the ineffective restrictions they put in place a couple of weeks ago:
- Disposable email addresses are now rejected.
- Email verification is now mandatory, most users are unaffected but new accounts must verify their email address via a time-limited token which is valid for 24 hours.
- Email changes are locked during the verification cooldown.
I wonder if they would benefit from switching to an invite tree, like what Lobsters has.
Yeah sorry, I wrote that comment assuming readers already knew.
I wonder if they would benefit from switching to an invite tree, like what Lobsters has.
It might help with moderation after the fact, but the population of the AUR is already pretty big, who would all get grandfathered I assume.
I'd also be worried that it'd reduce the amount of packages, ideally popular packages get promoted to extra, but that takes someone who wants to adopt it into extra and time, so there's simply a good chunk of packages that'll likely stay in the AUR.
No worries at all!
Yeah, I guess if you're retrofitting a tree it's not really a tree anymore: it's a forest or a DAG (if invites are "devalued", require multiple people to vouch for you). But given how weak the current restrictions are, I suspect any trust/reputation system would help.
Whatever happens, I do hope they're able to tighten things down to the point where they can reopen adoption, because like you said, the package names are going to get cluttered over time.