AUR And What Can Be Done Next
Hi all, Following recent supply chain incidents involving the AUR, I’d like to open a discussion regarding the current "open" submission model. To better defend against supply chain attacks and reduce the maintenance burden caused by low-quality submissions, I am proposing a transition to a batch-based submission system. Instead of the current continuous influx, we could implement a scheduled intake: *Submission Windows:* New packages are submitted throughout the month but held in a pending state. *Designated Review Cycles:* Verification occurs on a fixed schedule (e.g., the first Sunday of each month). *Quality Filtering:* Packages are audited for security and adherence to AUR standards. Non-compliant packages are rejected with feedback, allowing maintainers to iterate and resubmit during the next window. The goal is to create a mandatory "cool-down" and verification period that makes it significantly harder for malicious code to be distributed. While this would be a significant shift in workflow, it seems like a necessary step to address the current security landscape. I am interested in hearing perspectives from the TUs and current maintainers on the feasibility of this approach and whether it aligns with our current infrastructure capabilities. Best regards, Amal Krishna
On 6/17/26 5:43 PM, Amal Krishna wrote:
Hi all,
Following recent supply chain incidents involving the AUR, I’d like to open a discussion regarding the current "open" submission model.
To better defend against supply chain attacks and reduce the maintenance burden caused by low-quality submissions, I am proposing a transition to a batch-based submission system. Instead of the current continuous influx, we could implement a scheduled intake:
*Submission Windows:* New packages are submitted throughout the month but held in a pending state.
*Designated Review Cycles:* Verification occurs on a fixed schedule (e.g., the first Sunday of each month).
*Quality Filtering:* Packages are audited for security and adherence to AUR standards. Non-compliant packages are rejected with feedback, allowing maintainers to iterate and resubmit during the next window.
The goal is to create a mandatory "cool-down" and verification period that makes it significantly harder for malicious code to be distributed. While this would be a significant shift in workflow, it seems like a necessary step to address the current security landscape.
I am interested in hearing perspectives from the TUs and current maintainers on the feasibility of this approach and whether it aligns with our current infrastructure capabilities.
Best regards,
Amal Krishna
Hi, We appreciate the ideas but there's already a **huge** amount of different threads on that specific subject being discussed in the aur-general mailing list [1] right now. We are happy to hear and take people's ideas and thoughts into consideration for our current evaluation of how to improve things, but let's try to keep all of this happening centrally in the same mailing list (or better yet, in the same thread if possible). Thanks for your understanding :) [1] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/ -- Regards, Robin Candau / Antiz
participants (2)
-
Amal Krishna
-
Robin Candau