- Arch-general - lists.archlinux.org

Re: The certificate for signing /iso/2026.06.01/arch/boot/x86_64/* has expired
by Kusoneko 19 Jun '26

19 Jun '26

Hi, 1) I'd start by actually sending it to Pierre's email address instead of just saying "To pierre(a)archlinux.de" in the message. 2) probably the arch-general list instead of the aur-general list? cc'd both in this reply. Kusoneko. Jun 19, 2026 17:14:58 lao(a)snv0.com: > Hello! > > 1) > To:pierre@archlinux.de[To%3Apierre@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%3Dpierre(a)archlinux.de > [user@linuxbox ~]$ > > 2) > Where should I write instead of Arch-releng (Arch Linux Release Engineering) mail list?

1 0

Proposal for a simplier reporting experience
by Ruby 17 Jun '26

17 Jun '26

In the recent Arch News post, the following was said: […] please reach out to Arch staff via the aur-general mailing list with more information. This is a weird one for me personally. Sure, email probably prevents some spam, and the target userbase is Linux users, so I bet there’s more experienced people, but I really don’t like mailing lists. For something like reporting malicious content, especially for the AUR, where content can be freely submitted by most people, I wish packages just had some form of a “Report as Malicious” button. Trying to send this email, my first one to any of the Arch lists, it took me at least 20 minutes to figure out how. I had to find the link to the mailing list website, I tried the anon subscription, I sent the confirmation email, nothing happened. Tried sending this and got rejected. Then, I tried again. Created an account, got the confirmation email, clicked it, it errored. Refreshed, finally got confirmed. Then it told me that I “have a subscription request pending”. Meaning I have to wait, possibly multiple days, potentially for quite a long while, to even report a package. At this point, I feel like 90% of users would have given up trying to report the malicious content. Which is a big issue - time is key when it comes to fighting bad actors. So yeah, again, I wish packages just had some form of a “Report as Malicious” button. This could either go to an internal list or, if it’s easier to implement, keeping the workflow of moderators, just have it send an automated email from some automatic-reporting(a)aur.archlinux.org or whatever to the existing mailing list. This might require a captcha (like is required for SSO account creation), maybe sign-in, or both, but I do really think a (practically) one-click reporting solution would benefit everyone. People not as familiar or not wanting to interact with mailing lists can report packages, and moderators get quicker reports about malicious packages solely because there’s a greater user base that can report. While I do think the lower barrier of entry also causes some issues, like spam, something like a rate limit and/or verification (such as through login or similar means) should lower this, especially given people could, if malicious, also just spam the mailing list somewhat easily.

3 2

AUR And What Can Be Done Next
by Amal Krishna 17 Jun '26

17 Jun '26

Hi all, Following recent supply chain incidents involving the AUR, I’d like to open a discussion regarding the current "open" submission model. To better defend against supply chain attacks and reduce the maintenance burden caused by low-quality submissions, I am proposing a transition to a batch-based submission system. Instead of the current continuous influx, we could implement a scheduled intake: *Submission Windows:* New packages are submitted throughout the month but held in a pending state. *Designated Review Cycles:* Verification occurs on a fixed schedule (e.g., the first Sunday of each month). *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. The goal is to create a mandatory "cool-down" and verification period that makes it significantly harder for malicious code to be distributed. While this would be a significant shift in workflow, it seems like a necessary step to address the current security landscape. I am interested in hearing perspectives from the TUs and current maintainers on the feasibility of this approach and whether it aligns with our current infrastructure capabilities. Best regards, Amal Krishna

2 1

Evolution had become unbearably slow
by Ralf Mardorf 16 Jun '26

16 Jun '26

Hi, Evolution has become slower to start up. It takes a very long time to open. Once it's open, it takes a long time for the preview to work. When I try to compose a new email, it takes a very long time for a new email window to open for editing. I started Evolution from the command line, and there was a segfault related to a gst-plugin-lib, with instructions to remove it or on how to debug it. But when I start Evolution now, I no longer get those instructions. Therefore, I am unable to provide any further details on this matter. $ pacman -Q evolution evolution-data-server webkit2gtk-4.1 evolution 3.60.2-1 evolution-data-server 3.60.2-2 webkit2gtk-4.1 2.52.4-1 $ pacman -Q gst-libav gst-plugin-gtk4 gst-plugin-pipewire gst-plugins- bad gst-plugins-bad-libs gst-plugins-base gst-plugins-base-libs gst- plugins-good gst-plugins-ugly gstreamer qt-gstreamer lsp-plugins-gst gambas3-gb-media gst-libav 1.28.4-1 gst-plugin-gtk4 0.15.2-2 gst-plugin-pipewire 1:1.6.6-1 gst-plugins-bad 1.28.4-1 gst-plugins-bad-libs 1.28.4-1 gst-plugins-base 1.28.4-1 gst-plugins-base-libs 1.28.4-1 gst-plugins-good 1.28.4-1 gst-plugins-ugly 1.28.4-1 gstreamer 1.28.4-1 qt-gstreamer 1.2.0-4 lsp-plugins-gst 1.2.29-1 gambas3-gb-media 3.21.6-1 I couldn't find a corresponding bug report on gitlab.archlinux.org or gitlab.gnome.org, hence I’m going to make an exception and cross-post this. Regards, Ralf

5 13

Question about sagemath
by Philippe Delavalade 15 Jun '26

15 Jun '26

Hello. As root, I installed sagemath ; now, the script 'sage' is in /usr/sbin/ ; so when I'm user 'math', I can't access it. Shall I remove package (being root) and reinstalled it as user 'math' or is there a method by, for instance, creating a symlink from /home/math/bin to /usr/sbin/ ? I'm still a newbie for archlinux :-) Regards. -- Philippe

2 2

Questions about archived packages and arch linux malware
by fc26wuqa＠studserv.uni-leipzig.de 15 Jun '26

15 Jun '26

Hello, what is the process in deciding in archiving a package? And what are the reasons? And are there any channels where I can get notified if a package is getting archived? I noticed that the package `vim-airline` and `vim-airline-themes` got archived - I think just recently. Can someone tell me, why that happened? Do packages get archived, because they got malicious? Best, Lucienne

3 3

400+ Arch Linux AUR Packages Compromised in a Supply Chain Attack Deploying Infostealers
by Turritopsis Dohrnii Teo En Ming 15 Jun '26

15 Jun '26

Subject: 400+ Arch Linux AUR Packages Compromised in a Supply Chain Attack Deploying Infostealers Good day from Singapore, Here is an article which I would like to share. Article: 400+ Arch Linux AUR Packages Compromised in a Supply Chain Attack Deploying Infostealers Link: https://cybersecuritynews.com/arch-linux-aur-packages-compromised/ Date of article: 12 Jun 2026 Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Extremely Democratic People's Republic of Singapore 15 Jun 2026 Monday 3.41 pm Singapore Time

1 0

Malware reduction measures ideas
by nathan sasser 14 Jun '26

14 Jun '26

Will note that I'm not familiar with mailing lists. (I'm gen Z and have never touched this before) But looking through this, I have a few ideas, some for the AUR's side, others for the AUR helper's side, and some others that I'm not sure which side would need to contribute to implement it. I'll number these (1),(2),(3) in the order I said them for which side would probably need to work on. (1) 1: My first thought was that for packages that are orphaned and are also EOL or otherwise dropped by upstream i.e. not the AUR publisher, but the developers. The PKGBUILDs should be made read only and unadoptable without confirmation of a fork or the upstream devs picking it back up. Seems extreme I know, but it seems a good amount of the packages that are orphaned there (that aren't git packages) are for packages that are EOL by the original devs or were for stuff that was since merged into mainline versions. (3) 2: as an addendum to idea 1, there needs to be an ability to redirect updates to the mainline package if a fork's features are added to the mainline packages. (2) 3: for the AUR helper's side, some malware analysis pre-step is needed. This could be as basic as a hook for utils like traur or some way to run yara/yara-X scripts on it (yes, I'm aware I or someone else could do that very quickly these days, but testing it might be iffy unless the all clear is given on the AUR's side when it comes to the malware stuff, that and there's no known steps on spinning up a custom AUR like repo it seems, but I'd imagine it's very basic.)

5 4

npm, pip and friends
by Ralf Mardorf 13 Jun '26

13 Jun '26

Hi, the fact that npm and similar package managers currently pose an extremely high security risk (and soon pip as well?) comes as a complete surprise ;). Perhaps what's happening in the AUR right now is the so-called "silver lining" of a crisis. There are so many suggestions on how to make the AUR complicated, unusable, user-unfriendly, like fighting fire with fire, but perhaps it is finally time to put an end to this insane, unmanageable chaos in package management. Wake-up call Ralf

2 4

Re: Tip to avoid malware from AUR: add node package managers to your IgnorePkg
by Ralf Mardorf 12 Jun '26

12 Jun '26

On Fri, 2026-06-12 at 14:43 +0200, solsTiCe d'Hiver wrote: > but that is just indication. After all, if it installs a rootkit, it > can hide those things.. Thank you, no indication here. I don't have time at the moment, but the next step is to check against rootkits. Regards, Ralf PS: I think there's something wrong with the mailing list. An email I sent couldn't be delivered, and I can't access the Arch General Mailing List archive.

1 0