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

Suspicious AURs
by Andrea Fortu 19 Jun '26

19 Jun '26

I don't know if this is the best address to write to, but I wanted to point out that I found some suspicious AURs. They are as follows: * breeze-icons 6.27.0-1 * icoextract o.3.0-1 * kiconthemes 6.27.0-1 * oxygen-icons 1:6.27.0-1 * oxygen-icons-svg 1:6.27.0-1 I know these are just secondary mattresses, but I think they should be reported anyway. I will make a further report on Reddit where I will say that in addition to large packages like spotify or discord, you also need to be careful with these smaller repositories

2 1

A possible way to secure the AUR orphaned packages from being easy target for malicious scripts.
by Lukas Grumlik 18 Jun '26

18 Jun '26

Hi, Hope you are doing well. The recent attacks on orphaned packages have been worrying, and the current way adoptions work seems like a huge supply chain risk. Leaving thousands of unmaintained packages open for anyone to click and adopt makes the repository an easy target for malicious scripts. Instead of keeping the doors completely open, a safer approach would be to change how orphaned packages are handled. The moment a package loses its maintainer, it could go into a locked, read-only state. People can still download it and use it as it is, but the instant adoption button gets disabled. It stays locked until an actual user notices it is broken or outdated and submits a proper request to take it over, explaining why it needs updating. This alone would stop automated bots, as a script cannot fake a genuine build error or give a proper reason to adopt. Once a request is accepted, the new maintainer could be put on a temporary status. Instead of their first update going live immediately to everyone, it could go into a staging area where the system automatically checks the changes in the build file. If the update tries to point the source URL to a completely different, dodgy domain, or adds sketchy download scripts, the system blocks it before it hits the public index. If it looks clean, it gets pushed out normally. This puts a solid barrier in front of malicious actors without creating a mountain of extra paperwork for the team. It uses the community to flag what actually needs fixing, ensuring energy is only spent on software people are actively using. Would love to know if something like this could be considered to help secure the repository moving forward. Best regards, Lukas Grumlik Sent using

16 24

SSH auth denied for existing AUR account enbonnet
by Ender Bonnet 17 Jun '26

17 Jun '26

Hello, I have an existing AUR account: enbonnet. My uploaded SSH key fingerprint is: SHA256:DwAGgyvDn2BSghPNV3zpIooziHczj+oCDpBxYwXvuKE Verbose SSH to aur(a)aur.archlinux.org shows that the server accepts the offered Ed25519 key, then final auth fails with: Permission denied (publickey) I also tested: ssh -o IdentitiesOnly=yes -i ~/.ssh/aur -vT aur(a)aur.archlinux.org ssh -o IdentitiesOnly=yes -i ~/.ssh/aur aur(a)aur.archlinux.org help Could you please verify whether my account is fully active for SSH access and whether the uploaded key is associated correctly? Thanks. -- Ender Bonnet *enbonnet.com <http://enbonnet.com?source=email-sign>*

1 0

Homograph attacks - another reason eyeballs are not sufficient?
by Tom Hale 17 Jun '26

17 Jun '26

Even reviewing PKGBUILDs, there are things that I CAN'T see, see, eg homograph attacks[1] for a package that I've not installed before (no diff highlight). An example of a `source` array attack vector: - https://install.example-cli.dev # safe - https://іnstall.example-clі.dev # compromised See the difference? You can't. Neither can you via the terminal. Both 2nd-line `і` characters are Cyrillic (U+0456), not Latin `i`. The second URL resolves to an attacker's server. Don't believe me? Copy the 2nd url into your browser -- browsers solved this years ago, the 2nd displays as: http://xn--nstall-ovf.xn--example-cl-62i.dev/ So even if I know what sources a package should use, I may not be able to tell that they are actually being used. I believe this is yet another example as to why defence-in-depth via automated PKGBUILD scanners is needed. I care about community members with less experience than myself in reviewing PKGBUILDs. I don't (yet) know how to hook in some of the automated scanners that have been mentioned here into paru and yay pre-install hooks, but if YOU know I think it would be of great value to have this knowledge be much more widespread. I asked how to do it here: https://www.reddit.com/r/archlinux/comments/1u85cig/defense_in_depth_pkgbui… [1] https://en.wikipedia.org/wiki/IDN_homograph_attack

6 8

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

17 Jun '26

Greetings. The recommendation to read every and any AUR package before installing is certainly correct. Although it is also over my head because I would not have known of any of those malware attempts. So out of desperation, I drafted a AUR package scanner wrapping YAY and scanning every AUR package with a Claude LLM before installing. Its a first POC and I know nothing, but maybe some find it useful and want to join. We are all affected so lets work on this together. https://github.com/manticore-projects/aurscan In my tests, the consumed Token cost around 3 cent per package. Money well spent. Best and cheers Andreas

4 8

AUR package scanning with Atomdrift - offer to help
by Thomas Stromberg 16 Jun '26

16 Jun '26

[resending as my e-mail yesterday went to the moderation queue] I've been building out an open-source platform for supply-chain detection over the last 6 months, based on my previous work at Chainguard. While it's still a work in progress, the recent attacks have tipped my hand, so here it goes: https://atomdrift.org/ (Apache 2.0) TL;DR - We're building an automated local reverse-engineering and detection platform, powered by tiny local deterministic AI models, retrained constantly based on recent attacks and threat feeds. Because it uses other great open-source projects under the hood (tree-sitter, rizin, etc) rather than just pattern matching, it's immune to most obfuscation attacks. Atomdrift's detection is runnable via a simple rust CLI tool ( https://codeberg.org/atomdrift/scan) No special hardware required. If you have a local LLM, we support an optimized path for getting a second opinion from it via --interpret that provides a summary and steers confidence levels. While our training pipeline has been pulling from open-source marketplaces for months, yesterday we just started scanning AUR updates rather than new additions, and here's an example of what it looks like: https://lab.atomdrift.org/file/720b4275223cf0e27e60fdae069eba53b1869d44e46b… Here's a link to the Arch pipeline results: https://lab.atomdrift.org/arch/ I built this to help open-source, and would love to figure out how I can help ArchLinux with their supply chain issues - whether it's just discussing ideas, making a sustainable alert pipeline to what is up and running already, running the pipeline on your infra, or collaborating on development. As atomdrift both emits scores and lets you tune for a specific acceptable false-positive level, one idea for AUR could be automated review or publishing delay based on confidence levels. The compute-side runs on Arch, btw. Thomas

6 14

please unsubscribe from mailing-list
by Andreas Lehmann 15 Jun '26

15 Jun '26

3 2

Re: Idea for preventing malicious packages
by David C Rankin 14 Jun '26

14 Jun '26

On 6/13/26 1:43 AM, Ralf Mardorf wrote: > On Sat, 2026-06-13 at 01:23 -0500, David C Rankin wrote: >> You should add a "rep" for each AUR user. For each review the user >> should gain, e.g. +1 for the effort. Any review failure should cost, >> e.g. -50 and result in account suspension for X? days. > Hi David, > > we usually see eye to eye, but in this case we couldn't agree less. Point made. What I've distilled from all the suggestions, that would help with the AUR issue, not some other attack, and not protecting against the infinitely patient bad-guy, boils down to two possibilities: 1. A waiting period for adoption. (7, 14, 21, 30, whatever days, packages with npm/pypi/etc get manual review) 2. Review of the first X number of commits. (if just by script added to the workflow that checks keywords) The why not add (2) for all commits if it is not resource intensive. This doesn't prevent the infinitely patient bad-guy from waiting out the waiting period before deploying the malware, but they would still be caught by (2) if it does a good job. Nothing will be perfect, but if we can cut at 1600 package attack down to a 20 package attack, we've gone a long way toward protecting users and protecting AUR. This preserves AUR in it's current form with wide-open anonymous account registration but adds some guardrails against a mass attack to make AUR a less-inviting target. Further, (1) and (2) can simply be added to the workflow and do not require our non-existent human-in-the-loop. Though I still think the human-in-the-loop is the Cadillac version, (1) and (2) are doable and would help. I talked with the SUSE/openSUSE folks about what prevents the same thing from happening to OBS (see opensuse-factory list thread "How secure is OBS against package poisoning and which list to ask on?") The big differences are the OBS account and no orphan pool. Nothing prevents an OBS user from uploading a malicious file to their OBS account, but there are no anonymous OBS accounts. The only way the poisoning and upload would occur is (1) a malicious account got by the SUSE registration process, or (2) an existing OBS user's account was compromised. In either case the "scale" is limited to a one-at-a-time issue. Nothing in the AUR or OBS case protects against a poisoned upstream source. If we are thorough with the script in (2) above and had it scan the sources as well to flag keywords there, that could be mitigated to a degree. 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. With OBS that can occur as part of the build since the build is carried out by OBS, not on the user's machine. Even if (1) and (2) only cut the malware by 1/2, that's a lot of moderator time and user risk avoided. -- David C. Rankin, J.D.,P.E.

3 4

Re: AUR REPORT THREAD
by Jason Marinaro 14 Jun '26

14 Jun '26

Also just found all PKGBUILD's by user : https:// aur.archlinux.org/account/skarbricat[1] Have malicious stuff/code also. -------- [1] https://aur.archlinux.org/account/skarbricat

1 0

AUR REPORT THREAD
by Jonathan Grotelüschen 14 Jun '26

14 Jun '26

Hi everyone, we’re working hard to reset/delete all malicious commits and ban the accounts. If you find more malicious packages, please **send them as a reply to this email** to keep them all in one thread. Thanks! -- tippfehlr

33 83