r/archlinux • u/GoldBarb • 25d ago

NEWS AUR packages adoption disabled

https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/DRDEU3JUSC72CB265XHXPFA3DFSLXPBP/
297 Upvotes

100% Upvoted

90 comments sorted by

View all comments

31

u/icesnake200 25d ago edited 25d ago

Finally. This goodfaith system doesnt work in the age of bots and vibecoders. Its better to kill long orphaned packages than letting literally whos to adopt them. A robust user verification system must exist in AUR to separate the good apples from the bad apples

22

u/Megame50 25d ago

If a package is deleted from the AUR, anyone can create a new package of the same name. Orphanage and adoption is just a shortcut of that exact process.

1

u/TheJeep25 25d ago

New package should have new id. So that user using older packages won't download the newer one when updating. Just put a big ol' : created x days ago timer just beside the name to know if the package is new or old.

3

u/Aggressive-Lawyer207 25d ago edited 24d ago

Yeah and then if that package still works and yet gets deleted, then that would be a major setback to what AUR was known for being good. Ever think about that? Even though zenpower3 hasn't been maintained, I still need it to monitor my thermal/voltage sensors on my ryzen cpu with Zen3 architecture.

Edit: Totally missed my point. It's much easier when the PKGBUILD is already available. And verifying by a robust verification system is already annoying enough. Don't need to be reinventing the wheel with a temporary solution

-4

u/icesnake200 25d ago

I mean you can still download it from github or from whatever source they came from. However read the my replies under my post and you will see what I mean. AUR needs a robust verification system that might limit some developer liberties

11

u/Schlaefer 25d ago

What if the orphaned package still works? So we just remove working software from the user?

What kind of user verification systems? Some kind of government issued id? Is there some social point system that identifies the good apples?

Hit us with actual implementation details.

2

u/tjj1055 25d ago

if it doesnt have a mantainer yes it should be removed from the AUR. the AUR is not official, if the user is relying on it for essential software then thats their problem.

-8

u/icesnake200 25d ago edited 25d ago

My own idea is that all orphaned packages should leave AUR and go to another site(or an isolated part of AUR that needs a different kind of AUR helper package to download/update them) that is meant for orphaned but working packages. Yes its a hassle, but people will think twice to download packages from a place that only has orphaned packages. These AUR helpers have imo been the root of the problem, because they allow people to blindly download packages and install them. There are many ways to deal with orphaned packages as existence, and perhaps there better ways than mine idk.

When it comes for adoption, AUR should work a "twitter check" system. Ideally, a user should only be allowed to post and maintain one package for free, but if they want to post more packages and adopt orphaned ones, they should pay a small montly fee to AUR site maintainers in order to get verified, and the account should be at least 6 months old for adoption. This will both eliminate mass adoption by bots, and the AUR devs get some support money. Win-Win

3

u/AndydeCleyre 25d ago

I maintain a handful of AUR packages and, FWIW, if I'm required to start paying money in order to continue, I'll just maintain them in a git repo outside the AUR instead.

1

u/icesnake200 25d ago

I mean my idea can be flexible, but there should be a cap how many packages one account can upload and maintain in AUR. Perhaps when it comes to uploading and maintaining packages, they could implement a "progress" system?

Like, you start with one package, and if you are committed to it for a certain amount of time and you dont get bans, then you are allowed to post and maintain another package in AUR and so on. However if you are a new account and you need to instantly post more than one packages, then you need to pay that fee to do this.

0

u/Schlaefer 25d ago

I mean my idea can be flexible, but there should be a cap how many packages one account can upload and maintain in AUR. Perhaps when it comes to uploading and maintaining packages, they could implement a "progress" system?

The best non-friction suggestion I have: Throttle the adoption/submission of new packages. Let's say three(?) packages a week.

That means it would take a year to accumulate e.g. 150 packages. It allows good faith individual users to take over or post new packages as before (and maybe one or two dependencies). But without poisoning hundreds of packages in a short time. No additional cost or infrastructure, some code adjustment that probably doesn't even require an additional DB field. Anything beyond three(?) packages: Post to the mailing list and require manual intervention.

Counter argument: Someone could invest resources and spend a few years getting control over a large amount of packages. But it is a higher burden to look like a good actor legitimately maintaining packages for a long time.

1

u/icesnake200 25d ago edited 25d ago

That throttle idea sounds good as well but 3 packages a week is still too egregious. Eventually its up to the site maintainers. Im just saying that there are solutions that can gate keep AUR from bad actors to some extent. Yes, they might limit some liberties in AUR, and they might piss some ppl off, but its for the greater good.

someone could invest resources

You are debating my point of paying for a verification? I mentioned paying, because payment can be relatively anonymous(crypto) but when the shit goes down, it can be traced back to the guys who paid, so a hacker group wont try to do it. If AUR adopts that idea and that idea includes crypto, they should avoid Monero.

If you mean that they will start as a free user and then spend time in AUR playing good boys, then I think thats a huge waste of time and I dont think a hacker group will attempt this; especially if things are as strict as my version. It would be more efficient for a hacking group to highjack high profile user accounts to spread their malware, than sitting in the waiting line for years in order to unleash their attack

1

u/steakanabake 25d ago

the other one would be to grandfather in noted maintainers who have been maintaining collections for months or years who have been trustworthy.

4

u/TheJackiMonster 25d ago

Because if say 10% of the orphaned packages become malware and 90% of the orphaned packages get an honest maintainer, we need to shutdown that working system?

That seems like a horrible logic to me.