June 2026 - Aur-general - lists.archlinux.org

Can I re-have back some packages?
by Timothy Redaelli 14 Jun '26

14 Jun '26

Hi, I'm a deputy trusted user, can I rehave back a couple packages I created (AUR) and that now are corrupted with the bun hack so I can fix and maintain those? - ar-smileys - melis-wallet-bin Thank you

2 1

Re: Idea for preventing malicious packages
by sketch-hamlet-nape＠duck.com 13 Jun '26

13 Jun '26

Hi all, Yesterday I wrote a similiar thread on forum: https://bbs.archlinux.org/viewtopic.php?pid=2301093#p2301093 Cheers, Hexxal (aka silensys) Sent with Proton Mail secure email. On Saturday, June 13th, 2026 at 20:13, Claudia Pellegrino <auerhuhn_at_archlinux.org_sketch-hamlet-nape(a)duck.com> wrote: > Hi David, > > > > In the AUR case, any source scanning would have to be added as > > part of the makepkg process, and compute required would just be part of > > the build process if something like that is even doable. > Fyi, there’s some experimental work in progress (private, not endorsed > by Arch developers) to add pluggable, user-controlled upstream source > auditing to makepkg. [1] [2] > > Regards > Claudia > > > [1]: > https://gitlab.archlinux.org/auerhuhn/libmakepkg-srcaudit/-/blob/main/READM… > > [2]: > https://gitlab.archlinux.org/auerhuhn/libmakepkg-hexora/-/blob/main/README.… > >

1 0

Idea for preventing malicious packages
by Carson Coder 13 Jun '26

13 Jun '26

We very much need to find a solution for preventing malicious packages. My idea is to give each new user a "score", if a user makes a commit and there score is below some threshold that commit must be manually reviewed. When these commits then influence the user's score. For example, if a new user makes a simple commit (like updating the version of a package) their score might go up by one or not change at all. On the other hand, if they add a new package or make a major update to a package, their score would go up by more. That way a malicious user would need to actually make meaningful commits, which is harder to automate and at least does some good for the aur. I have said this idea already around 2 weeks ago and I am bringing it up again because it seems relevant. The problem with just flagging the first 10 commits is that its not very hard to automate updating the version of 10 packages. Or flagging commits for a week would just result in people waiting a week before making malicious commits.

5 5

Re: AURSCAN: scan AUR package with Claude LLM before installing
by Andreas Reichel 13 Jun '26

13 Jun '26

On Sat, 2026-06-13 at 06:12 +0200, Ralf Mardorf wrote: > On Sat, 2026-06-13 at 10:34 +0700, Andreas Reichel wrote: > > Claude LLM > > You cast out devils by Beelzebub! > > Your example "google-chrome" has got 2352 votes and was never > orphaned. Thank you again, I have updated the Readme w/ a more realistic example: $ syay firefox-patch-bin scanning firefox-patch-bin (3 files) ... [ MAL! ] firefox-patch-bin confidence 95% A source labelled "patches" points at a personal GitHub repo unrelated to Firefox and is executed during build — the July 2025 CHAOS RAT vector. [critical] PKGBUILD: Disguised source pulls attacker-controlled code. > patches::git+https://github.com/.../zenbrowser-patch.git ↳ tokens: 12,431 in / 214 out · $0.0413 scanner usage: 1 call(s) · tokens: 12,431 in / 214 out · $0.0413 !! Installation blocked: 1 package(s) flagged MALICIOUS. [A]bort (default) / [r]eport to mailing list & abort / [c]ontinue anyway:

1 0

Re: AURSCAN: scan AUR package with Claude LLM before installing
by Andreas Reichel 13 Jun '26

13 Jun '26

On Sat, 2026-06-13 at 06:12 +0200, Ralf Mardorf wrote: > On Sat, 2026-06-13 at 10:34 +0700, Andreas Reichel wrote: > > Claude LLM > > You cast out devils by Beelzebub! > > Your example "google-chrome" has got 2352 votes and was never > orphaned. Thank you for the feedback. It was just an illustration! And nobody claims that it is perfect! But when it is better than what I can achieve by reading the build source, then it is added value for me.

1 0

Likely Malicious Account: ivonahruskova
by Joom 13 Jun '26

13 Jun '26

This account was created June 11th using a bogus Gmail address, and took ownership of both vbam-git, and mingw-w64-geos. At the time of writing, there do not appear to be any malicious commits (I have a local copy of vbam-git's PKGBUILD, which was not updated yesterday when doing a git pull), but since this attack has been done in waves, it's possible these were being reserved for a third, especially since the account was created after previous waves. Account: https://aur.archlinux.org/account/ivonahruskova Packages: https://aur.archlinux.org/packages?K=ivonahruskova&SeB=m

1 0

Proposal: compile affected commit hashes + date ranges per package
by undefined undefined 12 Jun '26

12 Jun '26

Hello there, this is my first time using a mailing list :) I've run some checks on my machines and found that at least libgdata and subbrute are present on my PCs. However, they were both last updated several months ago, so I can't verify for sure whether the malware is present or not. I was thinking of cross-referencing expac info about installed packages against git log dates, but since the malicious commits were removed from the AUR with --force, I'm not sure how to do that anymore -- especially as my setup cleans .cache/yay regularly, so I don't have the local clones to inspect either. Having a list with the malicious commit hashes and dates would likely help automate checks for folks like me. Vladimir T

1 0

Proposal: Make AUR read only before we delete all the malware and figure an solution to it, to stop more coming
by Sigma Twoja-Stara 12 Jun '26

12 Jun '26

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.

16 16

Possible bad actor
by aur hpminc.com 12 Jun '26

12 Jun '26

User simongeisler adopted a package I orphaned so I went to check it out. User just registered 3 days ago and has adopted 16 packages. User hasn't updated any PKGBUILDs yet, so I can't say one way or the other if anything bad is going on. With all the malicious packages being uploaded lately by new users adopting orphaned packages I thought it was worth pointing out. Paul

1 0

Re: Proposal: Make AUR read only before we delete all the malware and figure an solution to it, to stop more coming
by Michael Shaw 12 Jun '26

12 Jun '26

On Friday, June 12th, 2026 at 8:31 PM, archlinux.slogan162(a)passmail.net <archlinux.slogan162(a)passmail.net> wrote: > Looking at the attack leveraging a small amount of accounts which are adopting a lot of packages within a very short amount of time, I wonder if a less nuclear solution may be to ratelimit/flag accounts that do so. That way, the bottleneck becomes the speed at which the attacker gains access to AUR accounts or creates them. The regular Captcha protection may be leveraged here. > > I apologize if a similar suggestion was already made. I definitely agree that some risk modelling can alleviate these mass attacks, however, setting up and tuning parameters, then testing that it actually does have preventative power, takes time. In my opinion, the direction we should take is freeze now, identify current threats (we now have multiple variants using other JavaScript package managers), then enact this new model when it's ready, as well as other mitigations, since that alone won't be enough.

1 0