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.)
Hi, I'm a gen Z regular AUR user too. On Sat, Jun 13, 2026 at 07:23:37PM -0500, nathan sasser wrote:
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.
(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.
In most cases, upstreams won't care about maintaining it, even if as simple as giving a nodding yes. Furthermore, the value of the AUR lies in how easy and free it is to make contributions. And a malicious maintainer could easily behave normally for a while, submit packages, make useful-looking updates, and still introduce malware later. Therefore, the proposed rule would mostly add friction for good will contributors without much improvements. -- Best regards, Xuelin Yang
Hi, me too. Maybe it would be enough to have AUR helpers display a big warning when upgrading a package that was orphaned before. Something along the lines of: “WARNING s: this package has been revived from an orphaned state, please check for any malicious activity manually!” and then a slightly more verbose confirmation phrase (e.g. writing the package name) if the installation should really be continued. If people actually follow that warning (which i realize is generally rather unlikely), we would maybe not need to restrict the AURs freedom at all and rely on the community to flag malicious packages before they infect anyone. Best regards, Timo
On 14.06.2026, at 3:47 AM, Xuelin Yang <xuelin@adamanteye.cc> wrote: Hi, I'm a gen Z regular AUR user too.
On Sat, Jun 13, 2026 at 07:23:37PM -0500, nathan sasser wrote:
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.
(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.
In most cases, upstreams won't care about maintaining it, even if as simple as giving a nodding yes. Furthermore, the value of the AUR lies in how easy and free it is to make contributions.
And a malicious maintainer could easily behave normally for a while, submit packages, make useful-looking updates, and still introduce malware later. Therefore, the proposed rule would mostly add friction for good will contributors without much improvements.
-- Best regards, Xuelin Yang
How often are users both 1) installing orphaned packages, and 2) not checking the PKGBUILD when their AUR helper explicitly asks them to? Arch docs are pretty explicit about the inherent risk in using the AUR and the known benefits of running a trim system. Like Xuelin said: any additional guardrails will create friction for maintainers. The existing request to review the diffs before installation is like when windows asks "are you sure you want to install an unsigned package?" Which plenty of users also ignored, usually when installing game cheats or Adobe cracking utilities. Users be usering. Were any of the infected packages this time around any sort of mission critical libraries? -Rosaria -------- Original Message -------- On Sunday, 06/14/26 at 03:05 Timoyoungster <timo.proemer04@gmail.com> wrote: Hi, me too. Maybe it would be enough to have AUR helpers display a big warning when upgrading a package that was orphaned before. Something along the lines of: “WARNING s: this package has been revived from an orphaned state, please check for any malicious activity manually!” and then a slightly more verbose confirmation phrase (e.g. writing the package name) if the installation should really be continued. If people actually follow that warning (which i realize is generally rather unlikely), we would maybe not need to restrict the AURs freedom at all and rely on the community to flag malicious packages before they infect anyone. Best regards, Timo
On 14.06.2026, at 3:47 AM, Xuelin Yang <xuelin@adamanteye.cc> wrote: Hi, I'm a gen Z regular AUR user too.
On Sat, Jun 13, 2026 at 07:23:37PM -0500, nathan sasser wrote:
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.
(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.
In most cases, upstreams won't care about maintaining it, even if as simple as giving a nodding yes. Furthermore, the value of the AUR lies in how easy and free it is to make contributions.
And a malicious maintainer could easily behave normally for a while, submit packages, make useful-looking updates, and still introduce malware later. Therefore, the proposed rule would mostly add friction for good will contributors without much improvements.
-- Best regards, Xuelin Yang
Hi, All. In Addition To "“WARNING s: this package has been revived from an orphaned state, please check for any malicious activity manually!” and then a slightly more verbose confirmation phrase (e.g. writing the package name) if the installation should really be continued.") If We have A Team Of Volunteers Who`s Only Job "Is To Keep Aur Safe From Supply Chain Atttacks" We Know, The Scale Is big, But It will also Help To make "Aur More Safe!" In The Upcoming Days I think, We Should Try To "Verify" Packages In Upcoming Days. We Can Like Instead Of Having Aur "Open" Every time, We can Do like A Monthly Submission Maybe? Developers Can Submit Their Project And After We Verify The Pakage Is "Safe" We can "Approve" Those, Which Are "Safe" And Reduce Risk Of New "Malwares" On 14/06/26 17:50, r054r14@pm.me wrote:
How often are users both 1) installing orphaned packages, and 2) not checking the PKGBUILD when their AUR helper explicitly asks them to? Arch docs are pretty explicit about the inherent risk in using the AUR and the known benefits of running a trim system. Like Xuelin said: any additional guardrails will create friction for maintainers.
The existing request to review the diffs before installation is like when windows asks "are you sure you want to install an unsigned package?" Which plenty of users also ignored, usually when installing game cheats or Adobe cracking utilities. Users be usering.
Were any of the infected packages this time around any sort of mission critical libraries?
-Rosaria
-------- Original Message -------- On Sunday, 06/14/26 at 03:05 Timoyoungster <timo.proemer04@gmail.com> wrote: Hi, me too.
Maybe it would be enough to have AUR helpers display a big warning when upgrading a package that was orphaned before. Something along the lines of: “WARNING s: this package has been revived from an orphaned state, please check for any malicious activity manually!” and then a slightly more verbose confirmation phrase (e.g. writing the package name) if the installation should really be continued.
If people actually follow that warning (which i realize is generally rather unlikely), we would maybe not need to restrict the AURs freedom at all and rely on the community to flag malicious packages before they infect anyone.
Best regards, Timo
On 14.06.2026, at 3:47 AM, Xuelin Yang <xuelin@adamanteye.cc> wrote: Hi, I'm a gen Z regular AUR user too.
On Sat, Jun 13, 2026 at 07:23:37PM -0500, nathan sasser wrote:
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.
(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. In most cases, upstreams won't care about maintaining it, even if as simple as giving a nodding yes. Furthermore, the value of the AUR lies in how easy and free it is to make contributions.
And a malicious maintainer could easily behave normally for a while, submit packages, make useful-looking updates, and still introduce malware later. Therefore, the proposed rule would mostly add friction for good will contributors without much improvements.
-- Best regards, Xuelin Yang
participants (5)
-
Amal Krishna
-
nathan sasser
-
r054r14＠pm.me
-
Timoyoungster
-
Xuelin Yang