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 <[email protected]> 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 <[email protected]> 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
