multiple malicious AUR updates

bartus · 2026-06-17 12:35:15

@seth @silensys

If I may interject, could we have a MR/PR feature in AUR to replace the whole `orphan request/adopt` idea?

* It would greatly reduce the ratio of orphaned packages, as active users can easily approve/reject PRs for hundreds of packages but only actively maintain a couple.
* Instead of giving carte blanche to a random account based on a written `orphan request`, give them the ability to post changes which in turn get approved/rejected by mods/maintainers.
* Instead of voting for packages, add voting for users/PRs
* If someone gets enough karma by merging lots of PRs with a high vote count - after a cooling-off period, they could be promoted to package maintainer.
* If a PR gets enough votes from active users, it could be merged automatically without mods' approval.

It won't prevent a slow, methodical attacker from gaining trust to compromise a popular AUR package but will prevent a mass campaign of infecting `orphaned` packages while preserving the ability for the new users to contribute.

From the AUR maintainer's perspective: I tend to adopt hundreds of packages because it was the only way to get them working again, as posting patches in the comment section rarely gets a response. But without the ability to upkeep all of them, they get `orphan request` and mostly get better under consecutive maintainers. Still some just get vandalised by LLMs or some misinformed users. Having the ability to actually post/review/merge PRs would allow me to keep an eye on most of them while actively maintaining only a handful of those I'm currently using (e.g: blender-git, gimp-git) and also easily contribute to one I'm using but not maintaining (freecad-git, luxcore-git)

Last edited by bartus (2026-06-17 12:50:02)

Trilby · 2026-06-17 12:46:57

bartus wrote:

could we have a MR/PR feature in AUR to replace the whole `orphan request/adopt` idea?

So that's basically creating a Trusted-User-Lite class which can submit AUR packages. Seth has already commented on the result of this in an only slightly different context: we'd get new unofficial sources popup (PKGBUILDS distributed on github, etc) so real people could submit their work while they try to jump through the hoops to become approved to submit to the AUR itself. Or more realistically, they'd just post the PKGBUILD on github and *not* bother with the AUR at all.

Note that I have maintained a good handful of AUR packages - most of them my own hobby projects, but a couple that once had a decent user base. But I've never submitted PRs for other packages. Under your proposal, I'd have no votes, and I'd be excluded from sharing any of my projects on the AUR. In order to use the AUR, I'd have to deliberately submit PRs for things I have no interest in. I'd be jumping through the hoops just to fake-earn some reputation. I assure you, countless users reputation-chasing-via-PRs will not result in better software or security.

Last edited by Trilby (2026-06-17 12:53:04)

Lone_Wolf · 2026-06-17 12:57:25

dasrubbellos wrote:

That's a fantastic idea! AUR helpers should have an option to automatically do that. Does aurweb have an API?

Yes, see https://wiki.archlinux.org/title/Aurweb_RPC_interface .
No idea if setting/receiving nofications is supported by it though.

bartus · 2026-06-17 12:59:28

Trilby wrote:

So that's basically creating a Trusted-User-Lite class which can submit AUR packages.

Not really rather co mainstream feature enhanced, we just replace the `writen orphan request` with ability to post PRs for existing packages and the ability to merge them by mods or community.
New users can still create new packages, vote, comment and add PRs to existing ones – only the ability to adopt packages by new users would be removed.

When I started to contribute to AUR `orphan request` looks like a nuclear option, but as posting comments with patches rarely ever worked, it became the default one.
I have some of my packages `orphan requestd` and vandalised by some LLM users, and if I had the ability to review proposed changes, it would resolve similar issues.

It is no silver bullet, as @seth pointed out, but the current ability to nuke the AUR repo by orphaning/adopting packages is no longer sustainable.

Last edited by bartus (2026-06-17 13:12:30)

5hridhyan · 2026-06-17 13:10:33

could we have a MR/PR feature in AUR to replace the whole orphan request/adopt idea?

From a security POV it sounds beneficial, though I'm not sure how it would be implemented (if it ever is).

Would existing maintainers be exempt, or would they also need to earn and maintain that "karma" before pushing updates?

like if I needed to maintain karma just to update packages I already maintain, I'd probably hit Disown on all of them, simply because I don't have the time or interest to participate in that kind of reputation system

TBH, just reading through those bullet points makes me feel suffocated imagining myself trying to use/contribute to the AUR under such a system.

bartus · 2026-06-17 13:19:39

5hridhyan wrote:

Would existing maintainers be exempt, or would they also need to earn and maintain that "karma" before pushing updates?

Nope, karma will replace the adopt feature. Merged PRs from new user will increase the karma and after a cadence period would promote the user to maintainer if package is orphaned.
To elivete the burden of PR review user who actively maintain packages on AUR will be able to vote on PR to get automatically merged without mods approval.

Last edited by bartus (2026-06-17 13:19:59)

dasrubbellos · 2026-06-17 13:22:30

Trilby wrote:

I assure you, countless users reputation-chasing-via-PRs will not result in better software or security.

Instead it will result in people PR'ing hundreds of small changes, flooding the actual maintainers with irrelevant work. This is akin to getting your name on a scientific publication to build a reputation, where people mow each other's lawns to get a mention from a friend.

Lone_Wolf wrote:

Yes, see https://wiki.archlinux.org/title/Aurweb_RPC_interface .
No idea if setting/receiving nofications is supported by it though.

Looks read only. I'm gonna look up which tool from which package allowed voting and see how they did it. Was it "aur vote" from aurutils?

Last edited by dasrubbellos (2026-06-17 13:29:14)

5hridhyan · 2026-06-17 13:24:23

bartus wrote:

To elivete the burden of PR review user who actively maintain packages on AUR will be able to vote on PR to get automatically merged without mods approval.

if I understood that right, instead of reviewing my own package's incoming fixes, I am now expected to spend time auditing and voting on PRs for packages I don't even use, just to help out the global queue?

If active users/maintainers barely have time to keep up with upstream updates for their own niche packages, they certainly aren't going to spend their evening reviewing diffs for someone else's package
also this feels like a massive security blindspot waiting to happen. If a PR can get auto-merged just by getting enough "votes" from community maintainers, a group of malicious accounts (or compromised ones) could easily collude to upvote and auto-merge malicious code
We'd go from catching malware during orphan adoptions to playing whack-a-mole with community-voted auto-merges.

Last edited by 5hridhyan (2026-06-17 13:36:15)

tridra · 2026-06-17 13:29:02

I think discussing numbers matters a lot here.

How many people would need to vote to approve a PR? Ideally that would be more accounts than we expect a hypothetical attacker to use, and there's still no guarantee that they can't push past that number.

How would someone qualify as an active user? Would they have to submit PRs or just log in? Even if they had to submit PRs to qualify, the last attack showed that can be automated.

How would a voting system impact the existing packages? I agree with @Trilby, I see huge delays if the a high number of votes is to be required.

This would also mean that every package on the AUR would be at risk, and if I were an attacker I'd go after popular packages. The risk of users getting a malware would be much higher if that happens compared to infecting random orphaned packages. Despite the high number of packages affected, I don't think I've seen anyone publicly saying they installed a compromised package in the last attack.

bartus · 2026-06-17 13:45:43

5hridhyan wrote:

I am now expected to spend time auditing and voting on PRs for packages I don't even use

Why would you? Certainly you find yourself in a situation when you find a patch for defunct package you've tried to install in an AUR comment. Just extended this with ability to have working PR system you can vote on to merge given changes when current maintainer is absent unresponsive while voting right is limited to active users.

Last edited by bartus (2026-06-17 13:47:23)

5hridhyan · 2026-06-17 13:53:35

bartus wrote:

Just extended this with ability to have working PR system you can vote on to merge given changes when current maintainer is absent unresponsive while voting right is limited to active users.

There is a massive psychological difference between "I figured out a quick fix for a defunct package I use, so I'll drop the diff in the comments for others" and "I am now entering a multi-user consensus and voting lifecycle to push an update."

If the maintainer is completely AWOL and unresponsive, who exactly am I waiting on to approve that vote? A detached group of "active users" who don't use the software?

If a package is dead or unmaintained, a PR system doesn't magically revive it; it just creates a staging area for unmerged code. If an active community doesn't exist around a specific niche package to maintain it, they aren't going to exist to vote on its PRs either. We would just end up with an unmanageable backlog of stale PRs alongside stale packages, except now with the added risk of a malicious group voting to push automated merges through the cracks...

bartus · 2026-06-17 14:04:03

tridra wrote:

Ideally that would be more accounts than we expect a hypothetical attacker to use, and there's still no guarantee that they can't push past that number.

You can't rely tell with proper data for stat model, (used to study computational physics and could have a crack at it) but consider current system when mods review single sentence statement for `orphan request` and grants the mainstream tights without even seeing what changes are proposed for the package or users adopts the orphaned package with single click.

I would start form one month quarantine period for a PR, and if neither mod nor current active user merge/vote the PR, system consider it valid. And after 3 consecutive PRs that wasn't reported as malicious user is granted the maintainer status for the package and is excluded form quarantine hold.

All the security features are about slowing down the attack to the point it can be securely managed not to prevent it at all. On a long enough timeline survival rate of everyone drops to zero.

Last edited by bartus (2026-06-17 14:24:39)

5hridhyan · 2026-06-17 14:13:48

bartus wrote:

I would start form one month quarantine period for a PR, and if neither mod nor current active user merge/vote the PR, system consider it valid.

Wait what!?, if a PR sits completely unreviewed and ignored for 30 days, the "system" just blindly trusts it and auto-merges it?

bruh, this is a straight up time-delayed backdoor pipeline, like I mean an attacker wouldn't even need to bother spinning up multiple accounts to manipulate votes or climb a karma ladder, they could just dump malicious diffs into hundreds of not so much popular/used or "neglected" packages, sit back, and wait 30 days for the platform to automatically distribute their malware to unsuspecting users, a lack of response or review should NEVER be treated as implicit protocol approval, especially when dealing w/ "build" scripts like PKGBUILDs, which it obviously and completely undercuts the core goal of stopping malicious updates!

Last edited by 5hridhyan (2026-06-17 14:16:32)

dasrubbellos · 2026-06-17 14:17:01

Lone_Wolf wrote:

Yes, see https://wiki.archlinux.org/title/Aurweb_RPC_interface .
No idea if setting/receiving nofications is supported by it though.
dasrubbellos wrote:
Looks read only. I'm gonna look up which tool from which package allowed voting and see how they did it. Was it "aur vote" from aurutils?

I might be talking to myself here, but a POST against "https://aur.archlinux.org/pkgbase/<pkgbase of your package>/notify" or respectively "unnotify" seems to do the trick. Now some bash and curl glue, handling the login token and it's only "aurnotify <pkg>" away from being very convenient.

loqs · 2026-06-17 14:21:13

bartus wrote:

I would start form one month quarantine period for a PR, and if neither mod nor current active user merge/vote the PR, system consider it valid. And after 3 consecutive PRs that wasn't reported as malicious user is granted the maintainer status for the package and is excluded form quarantine hold.

Look at current backlog for adoptions/merges/deletions. With AI assistance it would be trivial to ensure the moderators had a review queue of valid pull requests for orphaned packages that could not be cleared in 30 days. Which allows insertion of harmful requests with the system bypassed.

bartus · 2026-06-17 14:51:05

5hridhyan wrote:

just dump malicious diffs into hundreds of not so much popular/used or "neglected" packages, sit back, and wait 30 days for the platform to automatically distribute their malware to unsuspecting users

If no user in a span of 30 days installs the package and figures out there's a rootkit there, nor any mod within the month of quarantine is able to catch the malicious package update, then yes, this will be a successful campaign that could potentially hit none, as the package clearly was rarely used, if ever.
The current `orphan/adop` system basically results in a 0-day cull-off delay before such a campaign can be started.

noesoespanol · 2026-06-17 14:57:23

Sidekick wrote:

noesoespanol wrote:
Also, missing the big red notice "use at your own risk" is kind'a [...]
oh. Uh huh. The big red notice. Care to point me to where I can see this "big red notice"? All I see when clicking the AUR text is a pale blue bubble at the top that is easily disregarded as 'noise' as anyone with at least some training in UI design could tell you. Had I seen a big red notice I would've used the AUR in a much different manner and treated it a lot different.

https://wiki.archlinux.org/title/Arch_User_Repository

Looks pretty pretty pretty very red to me?

Also, AUR = arch USER repository.

loqs · 2026-06-17 14:59:03

bartus wrote:

5hridhyan wrote:
just dump malicious diffs into hundreds of not so much popular/used or "neglected" packages, sit back, and wait 30 days for the platform to automatically distribute their malware to unsuspecting users
If no user in a span of 30 days installs the package and figures out there's a rootkit there,

During the 30 day quarantine the change is not applied so this makes no sense or are you arguing the same users that do not read the PKGBUILD would read quarantined merge requests?

bartus wrote:

nor any mod within the month of quarantine is able to catch the malicious package update, then yes, this will be a successful campaign that could potentially hit none, as the package clearly was rarely used, if ever.

This relies on the previous incorrect assumption.

Last edited by loqs (2026-06-17 14:59:33)

bartus · 2026-06-17 15:17:09

loqs wrote:

users that do not read the PKGBUILD would read quarantined merge requests?

Yes, if the user needs the package and it's currently in a broken state and there's a PR that fixes the issue and the user votes on the PR and the PR gets merged and the author is promoted to maintainer because of the previous 2 working PRs already merged, I would consider this a working solution. If a user votes on a PR that contains a rootkit, or the current package maintainer approves the PR with a virus included, or a mod within the cool-off period doesn't catch the malicious commit, it would be a system failure.

I remember someone mentioning the SolarWind debacle in a YT vid, the biggest supply chain attack in US: "You can't prevent being compromised; you can only prepare yourself to menage one."

seth · 2026-06-17 15:35:35

bartus wrote:

The current `orphan/adop` system basically results in a 0-day cull-off delay before such a campaign can be started.

You cannot insta-orphan packages to snatch them, https://wiki.archlinux.org/title/AUR_su … nes#Orphan

bartus wrote:

I tend to adopt hundreds of packages […] posting patches in the comment section rarely gets a response. But without the ability to upkeep all of them, they get `orphan request` […] Having the ability to actually post/review/merge PRs would allow me to keep an eye on most of them […] and also easily contribute to one I'm using but not maintaining

tl;dr you're looking for a more effective issue tracker for AUR packages, the reputation system is tangential and a non-starter: it's exclusive, game-able and any defaulting to delayed auto-approval is… <tonystark>not a good plan</tonystark>

loqs has previously reasoned the costs and downside of a fork-structure à la github/gitlab, otherwise one could maybe move the aur to gitlab.archlinux.org - but the comment section is certainly not a good issue tracker.
Makes me wonder whether the github clone could be leveraged and its issue tracker mapped to the AUR users of the branches

5hridhyan · 2026-06-17 15:40:16

bartus wrote:

If no user in a span of 30 days installs the package and figures out there's a rootkit there, nor any mod within the month of quarantine is able to catch the malicious package update, then yes, this will be a successful campaign that could potentially hit none, as the package clearly was rarely used, if ever.

Why are you acting like my government? "less popularity == low value == ah yeah you can die"?

It wasn't really about the package or package popularity, it's about attack vectors and loopholes. Low-profile, unmaintained packages are prized targets precisely *because* fewer eyes are on them, allowing attackers to slip in backdoors, like someone goes "oh a android bootloader unlock tool! lemme grab it" and they are cooked

bartus wrote:

Yes, if the user needs the package and it's currently in a broken state and there's a PR that fixes the issue and the user votes on the PR and the PR gets merged...

you're shifting the burden of platform security onto regular users who just want to install an application. If a niche package is broken, a user running an AUR helper isn't going to log into a web UI, audit a raw diff, cast a "vote," and then wait for a quarantine to clear

for a 30-day quarantine period, wouldn't I just clone upstream and build it myself instead of waiting for the platform to move?

practically speaking, in 30 days upstream would have released "more" updates. If every single update requires a 30-day quarantine to clear, completing a single maintenance cycle would require months because of the "karma" gates. I mean like in short, the AUR would be like a Debian update cycle, but waaayy less testing and authority, it's a lose-lose match.

So what would be the solution? Nothing.
as many users on these boards have said multiple times, the AUR was never meant to be a safe haven. Users are responsible for vetting the PKGBUILD before installing or updating a package. Whatever UI/UX gamification, automated tools, or karma system you throw at it, none of that can save a user permanently. It just gives false "secured" hopes

Last edited by 5hridhyan (2026-06-17 15:46:47)

loqs · 2026-06-17 16:06:20

seth wrote:

loqs has previously reasoned the costs and downside of a fork-structure à la github/gitlab, otherwise one could maybe move the aur to gitlab.archlinux.org - but the comment section is certainly not a good issue tracker.
Makes me wonder whether the github clone could be leveraged and its issue tracker mapped to the AUR users of the branches

AURs one branch no forks limitations makes merge requests very difficult and probably blocks gitlab use as a frontend. Replacing aurweb with a highly customized/locked down gitlab instance separate from Arch's gitlab apart from single sign on would make merge requests more easier.
With the current limitations a user could push a branch 'update' that the AUR backend would hide and stage and prompt current maintainers for review. Upon acceptance either the branch is merged or to avoid adding merge requests to history the merge branch replaces the master branch. It is similar to the issue of embargoing commits it needs work hiding it in both the aurweb and native git feeds while gracefully handling all corner cases and not introducing performance bottlenecks.

The nuclear approach drop AUR. All the PKGBUILDs are available on the github mirror. Let interested parties put advertise replacements on the wiki.

Last edited by loqs (2026-06-17 16:07:24)

kiraxploit · 2026-06-17 16:28:42

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.

> Tell Me Your Thoughts

seth · 2026-06-17 16:44:46

loqs wrote:

AURs one branch no forks limitations makes merge requests very difficult and probably blocks gitlab use as a frontend. Replacing aurweb with a highly customized/locked down gitlab instance separate from Arch's gitlab apart from single sign on would make merge requests more easier.

Hence the idea to maybe just leverage the issue tracker on the github clone - no PRs, just a better way to report and track bugs/issues w/ the package than the comment section.
Though idk how big of a problem this really is w/ a properly maintained package and how much it can help if you're drowned in tasks anyway.
If this affects only a fistful of AUR maintainers maybe they could just mirror the packages on their github and put up a sticky comment to report problems there (which also allows for indirect PRs)

@kiraxploit, the essence of your proposal is for trusted users to sign off on AUR packages, I'm not sure what tacting that would help but it falls short on the scale of the problem.
Also the recent attacks specifically operated on hijacking orphaned packages, so limiting the approval to new submissions would have failed that scenario (as would w/ the maintainer submitting legit packages and then turning them malicious w/ an update)

loqs · 2026-06-17 16:50:33

kiraxploit wrote:

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.

Given the current backlog on aur-requests is the assumption that there would be a reduction in requests related to new packages that would offset the increased maintainer workload or that there is sufficient surplus maintainer time available to cover the reviews?

Last edited by loqs (2026-06-17 16:50:56)

Arch Linux

#126 2026-06-17 12:35:15

Re: multiple malicious AUR updates

#127 2026-06-17 12:46:57

Re: multiple malicious AUR updates

#128 2026-06-17 12:57:25

Re: multiple malicious AUR updates

#129 2026-06-17 12:59:28

Re: multiple malicious AUR updates

#130 2026-06-17 13:10:33

Re: multiple malicious AUR updates

#131 2026-06-17 13:19:39

Re: multiple malicious AUR updates

#132 2026-06-17 13:22:30

Re: multiple malicious AUR updates

#133 2026-06-17 13:24:23

Re: multiple malicious AUR updates

#134 2026-06-17 13:29:02

Re: multiple malicious AUR updates

#135 2026-06-17 13:45:43

Re: multiple malicious AUR updates

#136 2026-06-17 13:53:35

Re: multiple malicious AUR updates

#137 2026-06-17 14:04:03

Re: multiple malicious AUR updates

#138 2026-06-17 14:13:48

Re: multiple malicious AUR updates

#139 2026-06-17 14:17:01

Re: multiple malicious AUR updates

#140 2026-06-17 14:21:13

Re: multiple malicious AUR updates

#141 2026-06-17 14:51:05

Re: multiple malicious AUR updates

#142 2026-06-17 14:57:23

Re: multiple malicious AUR updates

#143 2026-06-17 14:59:03

Re: multiple malicious AUR updates

#144 2026-06-17 15:17:09

Re: multiple malicious AUR updates

#145 2026-06-17 15:35:35

Re: multiple malicious AUR updates

#146 2026-06-17 15:40:16

Re: multiple malicious AUR updates

#147 2026-06-17 16:06:20

Re: multiple malicious AUR updates

#148 2026-06-17 16:28:42

Re: multiple malicious AUR updates

#149 2026-06-17 16:44:46

Re: multiple malicious AUR updates

#150 2026-06-17 16:50:33

Re: multiple malicious AUR updates

Board footer