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