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

Confusion on usage scenarios of aur-requests mailing list
by hello＠ismailarilik.com 16 Jul '26

16 Jul '26

In the description https://lists.archlinux.org/mailman3/lists/aur-requests.lists.archlinux.org/ of the aur-requests mailing list, it states: > > Public mailing list for AUR package deletion/merge/orphan requests > But in aur.archlinux.org https://aur.archlinux.org/ , it says that requests should be filed using the Package Actions box on the package details page and the mailing list shouldn't be used for that purpose: > > If you want to discuss a request, you can use the aur-requests https://lists.archlinux.org/mailman3/lists/aur-requests.lists.archlinux.org/ mailing list. However, please do not use that list to file requests. > So which one is true?

2 1

AUR registration disabled
by Leonidas Spyropoulos 13 Jul '26

13 Jul '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 1

aur-mailware-check: The popular 101st LLM'd script / Isolated/chrooted building
by archlists＠lenucksi.eu 08 Jul '26

08 Jul '26

Hi List, the worst of the June 14th attack now seems to be past us (fingers crossed). Unfortunately I guess that it'll not be the last attack the AUR will see. Here's two points: a) aur-malware-check script Here's a link to a repo that has been quite popular during the event: https://github.com/lenucksi/aur-malware-check It started out as a collection / summary of the scripts distributed throughout the initial gists and then received contributions from others for another, fully unrelated "campaign" and the "russian spam" packages that were discussed on this list later. I then turned the initial shell scripts into Python with the intent of being as concise as possible, as standard lib-only as possible and as reviewable as possible together with the best possible grounding+connection in the original sources that are connected to a "campaign". Now it has a format that can take in additional malware "campaigns" in an easier way if they're sort-of similar to the previous ones or can be extended easy enough to fit other malware approaches. The script has been created with human review (multiple people) and LLM-assistance. So for those who hate the existence and/or the use of LLMs: Please ignore the script. For the others: Maybe it's something that could be of use when the next set of nasty people come around. More constructive human review/improvement welcome of course. b) Enforcing isolated chroot building of packages (or at least promoting what already exists) To my understanding the blast radius of the 14th of June campaign could have been limited to a good degree by enforcing the building of the PKGBUILD in a chroot/container/nspawn etc that is properly isolated against the host system it runs on. Of course, if the resulting package is infected past the build process and then does its ill work after / when being installed, this is of no help. I did find the devtools (https://gitlab.archlinux.org/archlinux/devtools) package, its pkgctl tool and of course the more recent AUR helpers such as paru have an optional --chroot parameter. However none of it is default, advertised properly or promoted as a good / best practice even though upon trying those they all worked quite well, didn't really take excessive amounts of disk space and didn't really extend the time to build and AUR package that much. I dug around the devtools package and how it is used today and added a few tweaks to it that run fine here. Basic point was: See to what degree the modern Linux capabilities can be used to isolate the build a bit better than what the current chrooted builds do. Also, isolate what the AUR builds download in terms of cached packages from the main cache. Provide an option to clean said cache after build. Since the Archlinux Gitlab is invite only, I have converted the changes to patches and attached them here. Maybe they are useful to someone. Cheers, Lenucksi --

2 1

Temporary Maintenance Delay for My AUR Packages
by shresth paul 07 Jul '26

07 Jul '26

Hello Everyone, I hope you're doing well. I will be away from active development and maintenance for a short period (likely around a month or 2 (max)) due to some personal circumstances. In case there are any issues related to the packages I currently maintain, please feel free to reach out to me via email. I will try my best to review and fix critical issues as soon as possible whenever I am available. Thank you for your patience and understanding. Thanks Shresth Paul (AUR UserName - SecByShresth)

3 5

AUR Account Creation Request: x4d1xyz
by beamzbyhakz＠proton.me 04 Jul '26

04 Jul '26

Hello AUR Maintainers, I would like to request the creation of a new AUR account, as the public web registration is currently disabled. Here are my account details: - Desired Username: x4d1xyz - Email: beamzbyhakz(a)proton.me I am the developer of "luma", an ultra-lightweight screen temperature daemon written in Rust, and I would like to publish and maintain the PKGBUILD for it in the AUR. My SSH Public Key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFqCXimE0j30VmvQ9JB7Pybph2cSNG4oXD5GP0K8tbeS beamzbyhakz(a)proton.me Thank you for your time and help! Best regards,x4d1xyz

2 1

Re: SSH not working
by Ramadan Ali 02 Jul '26

02 Jul '26

I can see you managed to push changes: ``` D:\>git clone aur@aur.archlinux.org:coderabbit.git Cloning into 'coderabbit'... remote: Enumerating objects: 57, done. remote: Counting objects: 100% (57/57), done. remote: Compressing objects: 100% (36/36), done. remote: Total 57 (delta 20), reused 57 (delta 20), pack-reused 0 (from 0) Receiving objects: 100% (57/57), done. Resolving deltas: 100% (20/20), done. D:\>cd coderabbit D:\coderabbit>git log commit 0ce85aa121f8ebcc7babf0249718ea3e72956f40 (HEAD -> master, origin/master, origin/HEAD) Author: Borna Punda <REDACTED> Date: Sun Jun 28 15:52:31 2026 +0200 coderabbit: version 0.6.4 Signed-off-by: Borna Punda <REDACTED> ```

4 4

Key signing?
by Sean E. Russell 01 Jul '26

01 Jul '26

Hi, I maintain a handfull of packages in AUR -- most of which I'm also the upstream author of -- and with all the recent hubub have been thinking about improving the trustability of those packages. I hadn't before really looked into signing since that seems mostly the domain of the core repositories and specifically signed _built_ packages (ignoring `-bin` packages in AUR for the moment). It occurs to me that my signature is going to have the most value to diligent checkers if it's signed by one of the trusted keys in `archlinux-keyring`, which of course leads me to wonder: is there a documented process for non-core contributors to get their keys signed? Arch Linux key signing parties, or something? There's a lot of discussion going on about a longer-term response to the supply chain attacks, and I'm sure a lot more less-visible discussion among the core team. In the meantime, I'd like to improve the trustability of the packages I maintain. I don't want to lose the enormous value AUR provides small (less popular) software developers and, ultimately, Arch users. --- SER Sean E. Russell (https://ser1.net) OpMsg: https://ser1.net/.well-known/opmsg.txt GPG key: https://ser1.net/.well-known/pgp.asc Minisign: https://ser1.net/.well-known/minisign.pub Age: age195vpft7nzsy83medxagqqsge0lrcuf9txe3z2znlu2wsk69cdu4sx8nfvp

7 8