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

[Proposal] Securing orphaned AUR packages and maintainer voting
by Aleksandar Zarić 21 Jun '26

21 Jun '26

Fellow Archers, Freedom of choice is our greatest strength. With that in mind, I would like to propose a solution regarding the recent AUR issues. My first proposal is to establish a public, read-only "orphanage" repository for orphaned packages. Only active maintainers with a proven reputation would be permitted to adopt packages from this repository. This would require a ranking or voting system for maintainers, potentially similar to the existing AUR voting mechanism. Adoption requests from the general public could then be processed via community voting or other established channels, such as the official forums. The second proposal is to automatically lock all orphaned packages from public modification. Upon adoption, the new maintainer would need to request an unlock from active maintainers. As with the first proposal, public adoption requests would be handled through voting or forum channels. I believe this is a straightforward, elegant, and secure approach for our community. I hope the Board will consider this proposal. Kind regards, Aleksandar Zarić - salexandarz

2 1

The certificate for signing /iso/2026.06.01/arch/boot/x86_64/* has expired
by lao＠snv0.com 19 Jun '26

19 Jun '26

Hello! 1) To:pierre@archlinux.de The certificate codesigning_pierre_archlinux.pem, used to sign the files `/iso/2026.06.01/arch/boot/x86_64/*` (used for Netboot, https://archlinux.org/releng/netboot/) expired on May 30, 2026, at 16:41:56 UTC. Steps to reproduce: [user@linuxbox ~]$ wget -q https://geo.mirror.pkgbuild.com/iso/2026.06.01/arch/boot/x86_64/vmlinuz-lin… [user@linuxbox ~]$ openssl cms -in vmlinuz-linux.ipxe.sig -inform DER -cmsout -print | grep -E 'notAfter:|subject:' notAfter: May 30 16:41:56 2026 GMT subject: C=DE, CN=Pierre Schmitz, emailAddress= pierre(a)archlinux.de [user@linuxbox ~]$ 2) Where should I write instead of Arch-releng (Arch Linux Release Engineering) mail list?

3 2

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

AUR registration disabled
by Leonidas Spyropoulos 15 Jun '26

15 Jun '26

Hey all, Due to the current influx of malicious packages uploaded to AUR registration of new accounts is currently disabled while we are working on the cleanup. Thanks for your understanding. Cheers, artafinde on behalf of Dev Ops of Archlinux -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368 244740D17C7FD0EC

1 0