Re: Proposal: Make AUR read only before we delete all the malware and figure an solution to it, to stop more coming

[Ariel Lieberman]

On 12/06/2026 10:58, David C Rankin wrote: On 6/12/26 2:22 AM, Iyán Méndez Veiga wrote: I think making AUR read-only would affect its functionality too much. I like the proposal of modifying the adoption step only. Perhaps adding a time delay is also enough, and would not add extra manual work to Arch Linux developers. For example, it could be something like this: Min account age before being able to submit a new PKGBUILD: 24h Min account age before being able to adopt orphan PKGBUILD: 7d Of course, this does not protect against account takeovers, or against patient attackers that can wait a week to adopt packages, but it would improve things a little bit without affecting AUR too much. They cannot simply create new accounts after old ones are banned, they have to wait another week. If all the attacks happened via the PKGBUILD adoption way, perhaps the requirements can be toughen even more, like requiring a min number of packages already being maintained by the account before allowing to orphan. I like those ideas,   I also think we can consider:   1) holding first X (10?) commits for new users until reviewed by human-in-the-loop; AND   2) holding commits for new users for X (30?) day period until reviewed by human-in-the-loop.   That does add moderator involvement on the *front-end*, but it would take no more moderator time than reverting changes to remove the malware and banning the user currently done on the *back-end*.   That would the malware from reaching AUR.   A big thanks to the moderators and the community's efforts. This is no fun, but appears to be a new-normal. Hi, Are there any statistics available on the usual amount of new user commits, lets say per week, when the AUR is not under attack? This could give an idea of the workload you suggestion would require. rellieberman