Auch ich verwende einige AUR Packages und habe sorgfältig die o.g. Links verfolgt und auch die zum ganzen Problem laufende Diskussion im AUR Forum. Zunächst die Links, sodass jeder ebenfalls sich leicht informieren kann:
- Aur-general - lists.archlinux.org = Die AUR Diskussionsliste
WTAKO Network = hier der AI-Anbieter, der freundlicher Weise gerade das gesamte AUR Repo mit seiner LLM scannt. Aktuell sind wohl noch 1.800 Packages zu scannen.
Aus der Diskussion im AUR-Forum habe ich den Tipp, zwei einfache Testprogramme im Terminal auszuführen:
Zunächst pkg-audit herunter laden und isntallieren (stammt aber leider auch aus AUR 
)
Im Terminal ausführen: pkg-audit
Dann erhält man eine Liste sämtlicher (!) auf dem eigenen PC installierter Packages, für die ein hohes Risiko von seiten Arch angegeben ist. Es bezieht sich also nicht nur auf AUR. Maßgebend ist der Eintrag in: https://security.archlinux.org Zuvor hatte ich noch sorgfältig alle nicht unbedingt nötigen AUR Packages deinstalliert und zwei AUR Packages durch flatpaks ersetzt. Das Erstaunliche am nun von pkg audit gezeigten problematischen Dingen ist für mich, dass allesamt aus den offiziellen Repos stammen und nicht aus AUR
djvulibre-3.5.30.1-1 is vulnerable to arbitrary code execution / no fix
pam-1.7.2-2 is vulnerable to arbitrary filesystem access / no fix
libxml2-2.15.3-1 is vulnerable to denial of service / no fix
grub-2:2.14-1 is vulnerable to multiple issues / no fix
systemd-261.2-1 is vulnerable to information disclosure / no fix
coreutils-9.11-2 is vulnerable to information disclosure / no fix
openjpeg2-2.5.4-1 is vulnerable to arbitrary code execution / No fix
openssl-3.6.3-1 is vulnerable to arbitrary command execution / No fix
libtiff-4.7.2-1 is vulnerable to denial of service / / No fix
perl-5.42.2-1 is vulnerable to signature forgery / no fix
linux612-6.12.101-1 is vulnerable to multiple issues / No fix
linux618-6.18.42-1 is vulnerable to multiple issues / No fix
libheif-1.23.1-1 is vulnerable to information disclosure / No fix
openvpn-2.7.5-1 is vulnerable to information disclosure / No fix
linux612-6.12.101-1 is vulnerable to multiple issues / No fix
linux618-6.18.42-1 is vulnerable to multiple issues / No fix
podofo-0.10.6-1 is vulnerable to multiple issues / No fix
perl-5.42.2-1 is vulnerable to directory traversal / No fix
cpio-2.15-3 is vulnerable to arbitrary command execution / No fix
wget-1.25.0-6 is vulnerable to information disclosure / No fix
giflib-6.1.3-2 is vulnerable to information disclosure / No fix
xdg-utils-1.2.1-2 is vulnerable to information disclosure / No fix
perl-5.42.2-1 is vulnerable to unknown / No fix
openssl-3.6.3-1 is vulnerable to certificate verification bypass / No fix
audacity-1:3.7.8-2 is vulnerable to information disclosure / No fix
lua51-5.1.5-13 is vulnerable to denial of service / No fix
linux612-6.12.101-1 is vulnerable to insufficient validation / No fix
linux618-6.18.42-1 is vulnerable to insufficient validation / No fix
linux612-6.12.101-1 is vulnerable to privilege escalation / – upgrade to
linux618-6.18.42-1 is vulnerable to privilege escalation / – upgrade to
nodejs-lts-jod-22.23.2-1 is vulnerable to denial of service / – upgrade to
Naja, da wird mir schon irgendwie anders, wenn ich sehe, wie viele problematische Komponenten auf meinem PC sind. Allerdings sind vermutlich die meisten Sicherheitslücken nur ausnutzbar, wenn Fremde meinen PC in die Finger bekommen oder wenn ich die Installation auf einem Server betreiben würde.
Den Tipp, mir die PKGBUILD anzuschauen, sehe ich auch als zu komplex an, denn damit kenne ich mich nicht aus. Ich könnte nicht beurteilen, was darin evtl. problematisch sein könnte.
Es gibt auch den Tipp, dass man sich einen chroot-Ordner anlegen sollte, in den man dann ein Package erst mal hinein entpackt und dann… ja was dann? – Ist mir ebenfalls zu komplex.
Die von mir verwendeten AUR Packages sind anscheinend alle OK. Allerdings habe ich in Pamac sicherheitshalber Updates für AUR vorerst deaktiviert.
Aus AUR verwende ich (falls es jemanden interessiert):
backrest (Sicherung von Anwendungsdaten)
Balena-etcher und electron 37
cnjifilter2 (für Canon-Drucker)
iscan + iscan-plugin-perfection-v330 + libstdc++5 + gtk2 (für meine Scanner)
krokiet (spürt doppelte Dateien auf zig Festplatten gleichzeitig auf)
hibiscus + jameica (HBCI-Homebanking)
opentabletdriver
simplescreenrecorder
samsung-unified-driver
Erfreulich finde ich, wie viele Menschen sich gerade im AUR-Forum Gedanken machen, wie man das ganze AUR-Konzept nachhaltig repariert im Sinne von Sicherheit. Die wichtigsten Vorschläge, die mir aufgefallen sind:
Alle Entwickler müssen ihre Packages PGP signieren.
Entwickler, die bereits seit z.B. 5 Jahren ihre Pakete dort haben und pflegen, erhalten eine Markierung als „schon eher zuverlässig“
Eine automatische Prüfroutine soll die Package-Build-Dateien analysieren, damit im Build nichts Schräges nachgeladen wird.
Das ARCH-Team sollte etliche Packages aus dem AUR in das Extra-Repo übernehmen, wo strenger geprüft wird. Manche User brauchen dann kein AUR mehr.
Langfristig wäre eine eigene OpenSource AI denkbar, die den Code analysiert und frei gibt oder sperrt.
Ach ja: Da ich vor dem letzten großen Update vom 29. Juli noch ein echtes Backup mit RescueZilla gerstellt hatte, könnte ich – selbst, wenn ich jetzt ein faules Paket installiert hätte – schnell wieder auf ein sauberes System zurück gehen.
Dauert aber noch etwas.