Proposal: Make AUR read only before we delete all the malware and figure an solution to it, to stop more coming
As i see, recently theres very much malicioud packages, that i decided to stop updating my aur packages. We could put aur read only, so we can remove all malware and figure solutions before new one arrives.
I think this is too nuclear. I agree with making it read only, but I really feel like there should be exceptions for certain important packages. I can't name any (because my memory is horrible) but somebody else can. On Friday, June 12th, 2026 at 6:13 AM, Sigma Twoja-Stara <sigmatwojastara@gmail.com> wrote:
As i see, recently theres very much malicioud packages, that i decided to stop updating my aur packages. We could put aur read only, so we can remove all malware and figure solutions before new one arrives.
As i see, recently theres very much malicioud packages, that i decided to stop updating my aur packages.
There's no need. As long as you inspect PKGBUILDs and verify that the changes are all right, you can keep updating.
We could put aur read only, so we can remove all malware and figure solutions before new one arrives.
That's a too harsh. I agree that the situation should be handled somewhat, but it can take weeks to come up with something and implement it.
As i see, recently theres very much malicioud packages, that i decided to stop updating my aur packages. We could put aur read only, so we can remove all malware and figure solutions before new one arrives.
It seems like only orphaned packages are affected. We could pause adoption or introduce a "human-in-the-loop" approach, though making the entire AUR read-only is too harsh and would affect legitimate packages and established maintainers. I am in favor of the human-in-the-loop approach, where contributors can push a commit to an orphaned package, but that commit is not reflected for anyone else—and the package is not officially adopted—until moderators approve the commit and the adoption. 1F616EMO
On 12/06/2026 09:12, 1F616EMO wrote:
As i see, recently theres very much malicioud packages, that i decided to stop updating my aur packages. We could put aur read only, so we can remove all malware and figure solutions before new one arrives.
It seems like only orphaned packages are affected. We could pause adoption or introduce a "human-in-the-loop" approach, though making the entire AUR read-only is too harsh and would affect legitimate packages and established maintainers.
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. -- Iyán Méndez Veiga GPG Key: 204C 461F BA8C 81D1 0327 E647 422E 3694 311E 5AC1
On 12/06/2026 09:22, Iyán Méndez Veiga wrote:
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 missed some words here. Just for clarity, what I meant was: "before allowing to (adopt) orphan (PKGBUILDs). -- Iyán Méndez Veiga GPG Key: 204C 461F BA8C 81D1 0327 E647 422E 3694 311E 5AC1
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. -- David C. Rankin, J.D.,P.E.
Hi all, reading all of this, it makes me wonder, do we need automatic adoption that badly? Orphan requests exist, after all, and that system seems to work just fine. To me it seems like package adoption should simply be a request too. If that is in place, adoption requests should also be able to be filed on a non-orphaned package, skipping the two-step orphan to adoption process. FWIW, I’m speaking as someone who has adopted multiple abandoned and/or archived AUR packages in the past. For all of these I would have not personally minded needing to go through a manual adoption process, especially since at least one of them is a widely-used tool. Maybe the numbers disagree with me on this, however, and there are so many adoptions that the maintainers will be overwhelmed. ~ kleines Filmröllchen Am 12.06.26 um 09:58 schrieb David C Rankin:
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.
Another temporary solution (specifically for the current situation involving atomic-lockfile npm package): regex npm/pnpm install atomic-lockfile in the PKGBUILD and holding all such commits. The regex list can then be updated manually by moderators as other methods of malware distribution get discovered. On Fri, Jun 12, 2026, 7:36 PM kleines Filmröllchen <kleines@filmroellchen.eu> wrote:
Hi all,
reading all of this, it makes me wonder, do we need automatic adoption that badly? Orphan requests exist, after all, and that system seems to work just fine. To me it seems like package adoption should simply be a request too. If that is in place, adoption requests should also be able to be filed on a non-orphaned package, skipping the two-step orphan to adoption process.
FWIW, I’m speaking as someone who has adopted multiple abandoned and/or archived AUR packages in the past. For all of these I would have not personally minded needing to go through a manual adoption process, especially since at least one of them is a widely-used tool.
Maybe the numbers disagree with me on this, however, and there are so many adoptions that the maintainers will be overwhelmed.
~ kleines Filmröllchen
Am 12.06.26 um 09:58 schrieb David C Rankin:
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.
That wouldn't really make much sense as we now have attacks with a different npm package (using bun to install /js-digest/). At least npm finally made atomic-lockfile a security holding package. https://socket.dev/npm/package/atomic-lockfile On 6/12/26 16:16, Agamjot Singh wrote:
Another temporary solution (specifically for the current situation involving atomic-lockfile npm package):
regex npm/pnpm install atomic-lockfile in the PKGBUILD and holding all such commits.
The regex list can then be updated manually by moderators as other methods of malware distribution get discovered.
On Fri, Jun 12, 2026, 7:36 PM kleines Filmröllchen <kleines@filmroellchen.eu> wrote:
Hi all,
reading all of this, it makes me wonder, do we need automatic adoption that badly? Orphan requests exist, after all, and that system seems to work just fine. To me it seems like package adoption should simply be a request too. If that is in place, adoption requests should also be able to be filed on a non-orphaned package, skipping the two-step orphan to adoption process.
FWIW, I’m speaking as someone who has adopted multiple abandoned and/or archived AUR packages in the past. For all of these I would have not personally minded needing to go through a manual adoption process, especially since at least one of them is a widely-used tool.
Maybe the numbers disagree with me on this, however, and there are so many adoptions that the maintainers will be overwhelmed.
~ kleines Filmröllchen
Am 12.06.26 um 09:58 schrieb David C Rankin: > 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. >
On 2026-06-12 16:16, Agamjot Singh wrote:
Another temporary solution (specifically for the current situation involving atomic-lockfile npm package):
regex npm/pnpm install atomic-lockfile in the PKGBUILD and holding all such commits.
The regex list can then be updated manually by moderators as other methods of malware distribution get discovered.
Circumventing such list is faster and easier than reacting and updating it to contain new patterns. The "payloads" are at least human readable for now... MW
All that's gonna do is make attackers push bad commits only when moderators have approved the good commit and adoption. -- Cheers, Aᴀʀᴏɴ
Making aur read only while clean up gets done then require use of a dial back service for any future submissions might be an improvement. a dial back service removes the submission part of aur from the internet since users have to use telephone modems to do their transactions and in order for the dial back service to work each submitter would need to provide the phone number for aur to dial them back if aur even has their phone number. One piece of malware and aur looses that submitter's phone number and maybe reports to interest officials in the country where aur repository exists. All phone calls all around the world are billable events so it's possible for police to call phone companies and give companiess a phone number date and time a call got made to that number and get the right company the company can tell police what account and where the call originateed.with dial back or ring back service calling police isn't necessary since aur has all the phone numbers. Last suggestion would be to do something the simtel archive did several years ago, all new submissions go into an incoming directory and stay there until they pass review.Sent from my Galaxy -------- Original message --------From: Aaron Liu <aaronliu0130@gmail.com> Date: 6/12/26 13:55 (GMT-05:00) To: aur-general@lists.archlinux.org Subject: Re: Proposal: Make AUR read only before we delete all the malware and figure an solution to it, to stop more coming All that's gonna do is make attackers push bad commits only when moderators have approved the good commit and adoption.-- Cheers,Aᴀʀᴏɴ
Since there are more and more packages and more and more variants, I'd like to second the proposal for a temporary read-only. I mean, most people won't update right now anyways, or shouldn't. On Friday, June 12th, 2026 at 08:14, Sigma Twoja-Stara <sigmatwojastara@gmail.com> wrote:
As i see, recently theres very much malicioud packages, that i decided to stop updating my aur packages. We could put aur read only, so we can remove all malware and figure solutions before new one arrives.
On Friday, June 12th, 2026 at 7:16 PM, archlinux.endeared273@passmail.net <archlinux.endeared273@passmail.net> wrote:
Since there are more and more packages and more and more variants, I'd like to second the proposal for a temporary read-only. I mean, most people won't update right now anyways, or shouldn't.
I'd also like to back the proposal of temporarily freezing the AUR. Since this is the new norm, anything we can do to avoid AUR becoming full-on npm is welcome.
As per the most recent announcement[1], it seems that this has been implemented. https://archlinux.org/news/active-aur-malicious-packages-incident/
participants (16)
-
1F616EMO
-
Aaron Liu
-
Adam Chovanec
-
Agamjot Singh
-
archlinux.endeared273＠passmail.net
-
Ariel Lieberman
-
CraftingDragon007
-
David C Rankin
-
Iyán Méndez Veiga
-
jdashiel
-
kleines Filmröllchen
-
Marcin Wieczorek
-
Michael Shaw
-
michaelsshaw704-hosted
-
nikooneshot.blurb049＠silomails.com
-
Sigma Twoja-Stara