multiple malicious AUR updates

kiraxploit · 2026-06-17 17:15:01

You make a fair point regarding the threat model my initial proposal for new submissions wouldn't address orphaned package hijacking or upstream account compromises. You're right that those are significantly harder problems to solve, and that shifting the workflow to a batch-based model introduces substantial friction for a potentially limited security gain.

Regarding your suggestion about moving issue tracking to external platforms (like GitHub): while that does improve tracking, it also creates a fragmented ecosystem where the "source of truth" for a package isn't centralized. However, your point about the maintainer burden is well-taken; any solution that adds more manual labor for TUs or package maintainers is likely a non-starter.

If a batch system is too heavy-handed and misses the most common attack vectors (orphaned/compromised accounts), perhaps we should shift the focus to hardening those specific areas.

Would it be more realistic to explore better automation for detecting suspicious changes in PKGBUILDs for orphaned packages, or perhaps mandatory MFA/higher friction for adopting orphans? I’m interested in what the community sees as the most viable "low-overhead, high-impact" security improvement, given that we are already operating at capacity.

seth wrote:

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)

kiraxploit · 2026-06-17 17:18:02

That’s a fair , I acknowledge that my previous proposal assumes a surplus of volunteer time that likely doesn't exist. You’re right; the "Package Maintainers" are already busy, and adding a mandatory review bottleneck would just create a massive backlog, likely leading to burnout or a stagnated repository.

The concern about orphaned package hijacking and maintainer account compromises is also fair those are the more common vectors than "new, malicious submissions," and a batch-approval system wouldn't touch those. Even Then I think we should keep an "eye on new packages"

If we move away from the idea of "centralized review" (due to the workload and scalability issues you pointed out), where does that leave us? Are there specific, lower-overhead mechanisms that could actually help without requiring a full-time audit team?

loqs wrote:

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?

seth · 2026-06-17 17:52:50

If we move away from the idea of "centralized review" […], where does that leave us?

Classic-Framed-Plus-If-You-See-Something-Say-Something-Wall-or-Door-Sign-Novelty-Funny-Warning-Signs-Small_5c36f0ff-cd07-4077-802f-add16ad8bc9c.de2b544aec8b16a0ba0df7ba386a7c00.jpeg?odnHeight=250&odnWidth=250&odnBg=FFFFFF

The status quo is to review a PKGBUILD before you run it and the decent thing is to report (eg. to the aur-general mailinglist) when you spot malware.
You're taking responsibility for your system and become part of a crowd-protection hive.

Trilby · 2026-06-17 19:25:41

Okay, going with the flow to offer what might be a reasonable option - that also will never be implemented:

1. When an AUR package is orphaned, it is randomly assigned to an existing active AUR contributor. "Active" would need to be operationally defined. Perhaps as having certain number of votes for packages maintained for some given period of time.

2. The new assignee then has a period of time (e.g., two weeks) to chose to A) adopt and maintain the package, B) assign it to another volunteer who has offered to maintain it, or C) let the package be deleted. There might then be a post-orphan-deletion period in which a package with that name cannot be resubmitted (without TU override).

This need not create much work for the assignee as they shouldn't need to actively search for a new maintainer. They would certainly be free to do so, but if it is known that the package is orphaned and that the assignee is the one to contact to volunteer help, then someone can contact the assignee. If after the 2-week period no one has contacted the assignee expressing interest in the package, then it probably should be deleted.

I imagine a "feature" could be added to AUR helpers to indicate to users of the package that it is orphaned and they should volunteer to maintain it or risk it being deleted.

noesoespanol · 2026-06-17 20:57:19

Trilby wrote:

Okay, going with the flow to offer what might be a reasonable option - that also will never be implemented:
1. When an AUR package is orphaned, it is randomly assigned to an existing active AUR contributor. "Active" would need to be operationally defined. Perhaps as having certain number of votes for packages maintained for some given period of time.
2. The new assignee then has a period of time (e.g., two weeks) to chose to A) adopt and maintain the package, B) assign it to another volunteer who has offered to maintain it, or C) let the package be deleted. There might then be a post-orphan-deletion period in which a package with that name cannot be resubmitted (without TU override).
This need not create much work for the assignee as they shouldn't need to actively search for a new maintainer. They would certainly be free to do so, but if it is known that the package is orphaned and that the assignee is the one to contact to volunteer help, then someone can contact the assignee. If after the 2-week period no one has contacted the assignee expressing interest in the package, then it probably should be deleted.
I imagine a "feature" could be added to AUR helpers to indicate to users of the package that it is orphaned and they should volunteer to maintain it or risk it being deleted.

This idea is kind'a cool actually, only thing is, I don't agree with deleting things, even if no one "owns" them, what if someday someone needs this? Maybe "lock" them into a read-only state and if someone wants to adopt it, they need to ask 3 "Active" people for it, for example. This way, things don't go under radar and at least 3 people are aware of someone taking something.

Last edited by noesoespanol (2026-06-17 20:57:50)

seth · 2026-06-17 21:15:39

B) assign it to another volunteer who has offered to maintain it

How does this prevent the malicious actor from collecting orphans by showing up as volunteer?
Does the randomly assigned victim have to do any background checks on them?
What if there're two volunteers and I pick the wrong one?
I just wanted to package this really popular new text editor everyone is talking about (ask me about sqriptor) and now I'm playing go… ok, bad example

We're not getting around the problem that you cannot have an open system where everyone can participate - except bad people.

There're currently 107.506 packages in the AUR, 13.038 orphans, ~ one update every 14 minutes (24/7, 102 per day) and 69 (nice) package maintainers to manage that circus (who are not working 7 days a week on the AUR, put your math away)
You could randomly send every commit to random 50 out of the 141964 registered users, but on average, 50 of those mails will be ignored. Probably also 500/500.

When you're installing or updating 1 package, that means you're interested in it. So why should *you* not be the one reviewing the patch *you* want to have?
And then if *you* happen to randomly spot something fishy, holding up your hand and pointing the finger of the other hand at the scary code is something *you* can actively do to support the ecosystem you benefit from.

And I get that you might be thinking "But I'm not good enough. I don't know how to read a PKGBUILD. And even if I try to figure what's going on - I can't spot any malware. I'll fail and install it and let everyone else down."
Read the Lord of the Rings.
Understand why all the morons crying "but the eagles could have dropped the ring into the volcano" haven't understood anything.
And it's also not like you've to make every close call all alone by yourself.

Trilby · 2026-06-17 22:14:22

seth wrote:

How does this prevent the malicious actor from collecting orphans by showing up as volunteer?

It doesn't prevent a malicious individual human from doing malicious things. But it 1) keeps a human in the loop of the decision - specifically one that has been active on the AUR already, and 2) it would prevent bots from claiming orphaned packages as there is no readily automated way to determine the assignee's email address and send them a request. Modern AI agents could likely manage this if properly prompted, but it'd be quite a lot of effort just to claim one package.

Malicious takeovers of orphans are done primarily by stupidly simple bot scripts running on orphan lists, not agentic AI bots implementing a directed and customized attack on a single orphan.

Note that I'm not suggesting the assignee would get automated email from some click on a webpage. Rather they're listed as the overseer of a given orphan in the same way they are of their existing packages. Their email address should be in one of their existing PKGBUILDs, quite likely masked or obfuscated in some manner. It'd be trivially easy for a motivated human to find their contact information, but likely impossible for a "standard" bot to do so, and possible but quite impractical for an AI agent.

Last edited by Trilby (2026-06-17 22:15:20)

seth · 2026-06-18 06:21:33

Malicious takeovers of orphans are done primarily by stupidly simple bot scripts running on orphan lists, not agentic AI bots

So the alternative would be
Screenshot-2020-12-17-at-19.38.11.png

If the idea is to make picking up an orphan more costly one could inject a random puzzle into the PKGBUILD (as comment) that the interested volunteer has to find and solve?

tridra · 2026-06-18 08:23:07

After all these discussions about needing warnings when a package becomes orphaned and whatnot, well, there are AUR helpers that already show that.

Recently I switched to paru (previously I was using rua). Here's paru's output after I checked for AUR updates today:

:: Looking for devel upgrades...
:: orphans: markdown-oxide-git
 there is nothing to do

I don't know how many helpers show this, but for those who care, this is already possible.

Lone_Wolf · 2026-06-18 09:02:23

Would raising the bar for adoption somewhat by removing the adopt package button and only allowing the procedure already used for deleted aur packages help ?

robg · 2026-06-18 09:05:39

I agree with Trilby that keeping a human in the loop is key.

I wonder if a system similar to the watchlist feature on the ArchWiki might prove useful? That is, maintainers of AUR packages may subscribe to others and be notified when a package is updated; this should (significantly?) increase the chance of detecting malicious PKGBUILDs in time.

In general, I believe that strengthening community oversight may a principled way forward. For instance, similar to Trilby's idea of randomly assigned maintainers for orphaned packages, I propose that maintainers receive review requests for statistically unlikely or suspicious changes such as many edits in a short time window by a new user.

Finally, I believe there are some low-hanging fruits such as limiting the number of daily account registrations, only allowing one account registration per IP, etc.

As for preventing the takeover of orphaned packages by bots, a (non-third-party!) Captcha should suffice.

noesoespanol · 2026-06-18 09:41:09

seth wrote:

B) assign it to another volunteer who has offered to maintain it
...When you're installing or updating 1 package, that means you're interested in it. So why should *you* not be the one reviewing the patch *you* want to have?
And then if *you* happen to randomly spot something fishy, holding up your hand and pointing the finger of the other hand at the scary code is something *you* can actively do to support the ecosystem you benefit from...

THIS, 1000 times THIS!

I think (most?) people forgotten what open source was and hopefully still IS about. It's not a hit and run thing, come get cookies and run eat them. You sometimes have to put a little effort and give back to the community that you take benefit from as well. Not just "OH MY God, IT'S BORKED VIRUS, WHY YOU NO FIX, ARCH SUX" kind'a attitude. I see this LOT on X (Twitter) and I guess it's younger generation coming into this arena and well, yeah.

Last edited by noesoespanol (2026-06-18 09:41:37)

noesoespanol · 2026-06-18 09:45:25

robg wrote:

...As for preventing the takeover of orphaned packages by bots, a (non-third-party!) Captcha should suffice.

This will never work. A.I. easily bypasses most of these now. They even bypass Cloudflare's anti bot, like a LOT of time. I have firsthand experience of this on a forum, where Cloudflare's all kinds of fancy shmancy protection is activated PLUS AbuseIPDB and STILL thousands of it coming through. Not one or two, they come in by the thousands! What's one little Captcha gonna do?

On the other point, yes, I think a human in the middle somewhere somehow is a good check but never a guarantee of course.

Last edited by noesoespanol (2026-06-18 09:47:01)

dasrubbellos · 2026-06-18 09:47:56

tridra wrote:

:: Looking for devel upgrades...
:: orphans: markdown-oxide-git
 there is nothing to do
I don't know how many helpers show this, but for those who care, this is already possible.

It would be useful if the helpers could warn about changes in maintainers and adoption status. As it is right now, that would require either the helpers keep track of that data and try and guess, or the AUR RPC couldprovide some sort of history:

2026-06-18T11:39:54+02:00 CoMaintainerRemoved Lone_Wolf
2026-06-18T11:39:26+02:00 CoMaintainerAdded Lone_Wolf
2026-06-18T11:38:40+02:00 StatusChange Adopted
2026-06-18T11:38:40+02:00 MaintainerAdded dasrubbellos
2025-06-15T14:36:50+02:00 StatusChange Orphaned
2025-06-15T14:36:50+02:00 MaintainerRemoved dasrubbellos

And the helper could match that against the installation date of the package and warn the user.

tridra · 2026-06-18 10:41:05

It would be useful if the helpers could warn about changes in maintainers and adoption status.

Since there's no vetting process, that would make no difference. It would only create a false sense of security for users who don't want to read the PKGBUILD. "Oh look, a new update. It's from the same maintainer, I guess it's fine, I already trust that maintainer." This should not be a thing.

The way I see the warning about orphaned packages is: a package I care about doesn't have a maintainer. If I care enough I can adopt it, otherwise I can evaluate alternatives.

dasrubbellos · 2026-06-18 11:22:46

tridra wrote:

Since there's no vetting process, that would make no difference. It would only create a false sense of security for users who don't want to read the PKGBUILD. "Oh look, a new update. It's from the same maintainer, I guess it's fine, I already trust that maintainer." This should not be a thing.

That's an extremely weak argument. Every piece of information can be used by the lazy and dumb to talk themselves out of their responsibilities.

You think a publicly available history of maintainer changes that do not rely on somebody archiving emails is a bad idea? A changelog is a bad idea? The absence of a vetting process is exactly why I want to be informed when the maintainer changes.

Good thing this information is already available for people subscribed to the package: Comment, Update, Adopt Disown, Delete, they all trigger a notification to a subscribed user. The only thing missing, if I don't misunderstand the sourcode, is a notification to a subscriber when a co-maintainer is being added. The information I am looking for is the history of the package metadata of a package I've never interacted with or haven't been subscribed to for a while.

seth · 2026-06-18 11:26:03

That's an extremely weak argument.

The argument is to not train users into bad habits like only/mostly/primarily paying attention to maintainer shifts (and start to get lazy otherwise)
If you review the PKGBUILD as supposed to, a maintainer change will not escape you.
If you're not reviewing the PKGBUILD as supposed to, you're doing it wrong.

tridra · 2026-06-18 12:07:55

You think a publicly available history of maintainer changes that do not rely on somebody archiving emails is a bad idea? A changelog is a bad idea? The absence of a vetting process is exactly why I want to be informed when the maintainer changes.

A changelog of past maintainers won't add any useful information to the PKGBUILD that you're already supposed to read.

I don't know if you personally want to use this information or you think people in general should rely on it, but if it's the former, you can easily implement a solution for yourself. You can check for AUR packages updates before updating and use that list to query AUR API then store the maintainer name on your PC for future comparison. Or you can patch the AUR helper you're using to integrate that in the helper, even submit a PR if you want.

duaner · 2026-06-19 02:46:05

I just took another look at the AUR wiki entry, and I wonder if it would help to have more specifics a newbie could look for, spelled out under "Verify the PKGBUILD" -- maybe a link to a page of training material on how to review the files. Is there a short list somewhere of ways people have tried to sneak malware into AUR packages before (other than going through reams of mail/posts)? I've been using Arch off and on for decades, but I still don't feel confident in my ability to spot a malicious edit.

For example, V1del saying, "FWIW a post install trying to do anything other than a simple informational echo should make you pause regardless," struck me as something I should have thought of a long time ago but never did.

I realize that there are infinite ways to attack, and don't want to build a false sense of security. And, of course, having the documentation does no good if no one reads it.

seth · 2026-06-19 06:43:18

https://bbs.archlinux.org/viewtopic.php?id=313955
The article has a "How Malicious PKGBUILDs Slip Through Casual Review"
But remember the xz attack? The guy wanted to figure where a performance loss was coming from.
You don't "spot" malicious edits (unless they're in your face), usually it start with "this feels wrong" and "why the fuck" and "I have a fundamental bias against <new dependency>"
If this starts to happen you look into it, what means to google what you don't understand and straight up ask an AI or here "What does this weird script do? I didn't even know my keyboard has those letters…"

It's not about being sure that there's malice, it's about being unsure that there's not.

dasrubbellos · 2026-06-19 08:22:56

@seth

Yeah, that's not what this is about. I get why you might have thought that, given my earlier comments about integrating it into AUR helpers. It's not about user convenience, it's about additional data sources for auditing the the package metadata beyond the git log. Your own separate thread is about PKGBUILD audit pitfalls. I don't just want to audit the package content, I want to audit the package. I was thinking about providing the information via the RPC, because visiting a website is fine for a few packages with infrequent updates, but not en masse.

You think adding such a feature will train users to not pay attention, I say it'll create awareness. AUR helpers created this mess by making the AUR an interesting target. They won't go away. Might as well equip them with useful tools.

tridra wrote:

A changelog of past maintainers won't add any useful information to the PKGBUILD that you're already supposed to read.

I never said that. Hyper-focusing on the PKGBUILD is your prerogative, of course, but you're ignoring every other security and trust principle around it because of a singular method you think works for you.

Last edited by dasrubbellos (2026-06-19 08:29:17)

SimonJ · 2026-06-19 08:36:08

Yay has had an update to implement some changes, so work is already started on this.

https://itsfoss.com/news/yay-v13-release/

seth · 2026-06-19 10:50:46

@dasrubbellos

Your own separate thread is about PKGBUILD audit pitfalls

Not exactly. It's about the nature of the AUR, why the lack of trust is structural, how to perceive it and that the article precedes and predicts the current situation, ie. nothing of this is really news.

However and to make this unambiguous: anything that forces and helps the user to review the PKGBUILD (changes) is good, anything that highlights isolated changes and therefore is prone to make the user ignore everything else is terrible.

And in case that's not clear: the change in authorship *will* show up in the git log (so what additional data sources are you talking about here?) but is in itself still completely meaningless wrt to the quality of the PKGBUILD itself.
The maintainer having changed does not at all indicate that there's something fishy and the maintainer not having changed does not at all indicate that everything's a-ok.

progandy · 2026-06-19 16:36:22

seth wrote:

And in case that's not clear: the change in authorship *will* show up in the git log (so what additional data sources are you talking about here?)

Not even that is reliable at the moment. Currently, neither commit author, committer, nor the maintainer lines in the PKGBUILD are verified, so you need to use the AUR metadata to detect maintainer changes for now. There are ideas to change that though with either adding metadata directly in git or commit emails to be verified with the aur profile.

Last edited by progandy (2026-06-19 16:48:49)

seth · 2026-06-19 17:08:00

I didn't mean the PKGBUILD diffs but the git metadata.

If you're allowed to push commits by other (impersonated) identities that's certainly less than ideal (and raises the question why the recent attacks even bothered) but also doesn't change too much about relying on the patch author being a mistake.
Rather it poses a further risk to rely too much on this data because you might spot the maintainer change and check the commits of the new maintainer, but not the ones that have been made w/ the identity of the previous author.

Arch Linux

#151 2026-06-17 17:15:01

Re: multiple malicious AUR updates

#152 2026-06-17 17:18:02

Re: multiple malicious AUR updates

#153 2026-06-17 17:52:50

Re: multiple malicious AUR updates

#154 2026-06-17 19:25:41

Re: multiple malicious AUR updates

#155 2026-06-17 20:57:19

Re: multiple malicious AUR updates

#156 2026-06-17 21:15:39

Re: multiple malicious AUR updates

#157 2026-06-17 22:14:22

Re: multiple malicious AUR updates

#158 2026-06-18 06:21:33

Re: multiple malicious AUR updates

#159 2026-06-18 08:23:07

Re: multiple malicious AUR updates

#160 2026-06-18 09:02:23

Re: multiple malicious AUR updates

#161 2026-06-18 09:05:39

Re: multiple malicious AUR updates

#162 2026-06-18 09:41:09

Re: multiple malicious AUR updates

#163 2026-06-18 09:45:25

Re: multiple malicious AUR updates

#164 2026-06-18 09:47:56

Re: multiple malicious AUR updates

#165 2026-06-18 10:41:05

Re: multiple malicious AUR updates

#166 2026-06-18 11:22:46

Re: multiple malicious AUR updates

#167 2026-06-18 11:26:03

Re: multiple malicious AUR updates

#168 2026-06-18 12:07:55

Re: multiple malicious AUR updates

#169 2026-06-19 02:46:05

Re: multiple malicious AUR updates

#170 2026-06-19 06:43:18

Re: multiple malicious AUR updates

#171 2026-06-19 08:22:56

Re: multiple malicious AUR updates

#172 2026-06-19 08:36:08

Re: multiple malicious AUR updates

#173 2026-06-19 10:50:46

Re: multiple malicious AUR updates

#174 2026-06-19 16:36:22

Re: multiple malicious AUR updates

#175 2026-06-19 17:08:00

Re: multiple malicious AUR updates

Board footer