Es gibt Momente in der Linux-Welt, da passiert etwas Ernstes.
Zum Beispiel, wenn im Arch User Repository verwaiste Pakete übernommen, Build-Anweisungen manipuliert und bösartige Abhängigkeiten nachgeladen werden.
Und dann passiert noch etwas Zweites:
Die Reaktion darauf wird fast genauso interessant wie der Vorfall selbst.
Denn plötzlich ist die Unsicherheit groß. Manche Nutzer sind erschrocken, andere wütend, wieder andere wirken, als hätten sie gerade zum ersten Mal gemerkt, dass das AUR kein offiziell geprüfter App-Store ist.
Und genau da wird es spannend.
Nicht, weil der Vorfall harmlos wäre. Ist er nicht. Wenn hunderte, später über 1.500 und nach weiteren Meldungen sogar über 1.900 AUR-Pakete oder Paketänderungen betroffen beziehungsweise gemeldet sind und Arch selbst eingreifen muss, dann ist das kein kleines „Ups“ im Maschinenraum.
Aber bei einem Repository mit über 100.000 Paketbeschreibungen ist es eben auch nicht so, als wäre plötzlich ganz AUR oder gar Arch in Flammen aufgegangen.
Der eigentliche Punkt ist ein anderer:
Das AUR war nie sicher im Sinne eines offiziellen, geprüften Repositories.
Es war nie der Linux-Supermarkt mit Sicherheitsdienst am Eingang, Kameraüberwachung und einem Arch-Mitarbeiter, der jedes Paket vor dem Einräumen nochmal liebevoll abklopft.
Es war immer ein Community-Ort. Ein riesiger Werkzeugschuppen. Voller nützlicher Dinge, aber eben auch voller Dinge, bei denen man besser hinschaut, bevor man sie anfasst.
Und viele haben diesen Werkzeugschuppen jahrelang behandelt wie ein All-you-can-eat-Buffet:
Augen zu.
Enter.
Wird schon passen.
Jetzt ist der Aufschrei groß.
Verständlich.
Aber ein bisschen wirkt es eben auch so, als würden Leute jahrelang barfuß durch eine Garage laufen, irgendwann auf einen Nagel treten und dann empört fragen:
„Warum liegt hier ein Nagel?“
Die Antwort ist unangenehm einfach:
Die lagen da schon immer.
Man wollte nur nicht hinschauen.
Was passiert ist
Fangen wir mit dem trockenen Teil an.
Am 11. Juni 2026 tauchten in der Arch-Community konkrete Hinweise auf verdächtige Änderungen im AUR auf. In der Mailingliste aur-general wurden mehrere Pakete genannt, bei denen neue oder geänderte Maintainer plötzlich verdächtige Installationslogik ergänzt hatten.
Ein neuer Maintainer hatte Pakete übernommen und Install-Dateien oder Build-Anweisungen ergänzt, die nicht einfach nur Software bauten, sondern während der Installation zusätzliche Pakete aus anderen Ökosystemen nachladen sollten.
Zum Beispiel über npm.
Also nicht:
„Hier ist der Quellcode, bau mir daraus sauber ein Paket.“
Sondern eher:
„Während du dieses AUR-Paket installierst, zieh bitte noch schnell fremden JavaScript-Kram aus dem Internet nach und führe dessen Installationslogik aus.“
Das ist so ein Moment, bei dem man nicht sofort aus dem Fenster springen muss.
Aber man sollte wenigstens kurz die Kaffeetasse abstellen.
Denn ein AUR-Paket, das plötzlich während der Installation ein npm-Paket namens atomic-lockfile nachlädt, ist kein kleiner Schönheitsfehler. Das ist kein „Ups, falsches Icon im Menü“.
Das ist eher:
„Da hat jemand einen Lieferwagen vor den Seiteneingang gestellt und möchte jetzt bitte unkontrolliert Kisten ins Gebäude tragen.“
In derselben Diskussion wurden weitere betroffene Pakete genannt. Nach und nach wurde klar, dass es nicht um einen einzelnen Paket-Kobold ging, sondern um eine größere Kampagne.
Sicherheitsforscher von Sonatype beschrieben den Angriff später unter dem Namen „Atomic Arch“. Laut ihrer Analyse zielten Angreifer darauf ab, verwaiste oder wenig gepflegte AUR-Pakete zu übernehmen und deren Build- oder Installationsanweisungen so zu verändern, dass bösartige Abhängigkeiten nachgeladen wurden.
Zunächst ging es vor allem um npm. Später tauchten weitere Varianten auf, darunter Mechanismen über Bun und andere verdächtige Abhängigkeiten wie js-digest oder lockfile-js.
Das Muster blieb ähnlich:
Verwaistes oder schwach gepflegtes AUR-Paket übernehmen.
PKGBUILD, Install-Datei oder Hook verändern.
Eine fremde Abhängigkeit aus einem anderen Paket-Ökosystem nachladen.
Darüber einen Payload ausführen lassen.
Und dann hoffen, dass Nutzer einfach Enter drücken.
Das ist kein Hollywood-Hack mit grünen Zahlen auf schwarzem Bildschirm.
Das ist viel banaler.
Und genau deshalb so unangenehm.
Arch musste eingreifen
Am 12. Juni 2026 veröffentlichte Arch Linux selbst eine Meldung zum aktiven Vorfall. Dort war von einem hohen Volumen bösartiger Paket-Adoptionen und Updates im AUR die Rede.
Während der Aufräumarbeiten konnten Nutzer zeitweise Probleme bei bestimmten Funktionen sehen, zum Beispiel beim Erstellen neuer Accounts, beim Pushen von Paketupdates oder beim Adoptieren und Anlegen neuer Pakete.
Das ist wichtig.
Denn wenn Arch an solchen Stellen bremst, dann nicht, weil irgendein Forenkommentar zu laut geatmet hat.
Dann ist wirklich etwas los.
Die Zahlen änderten sich im Laufe der Untersuchungen mehrfach. Erst war von über 400 betroffenen Paketen die Rede. Später wurden Listen mit deutlich über 1.500 Paketen genannt. Nach späterem Stand kursierten Zählungen mit über 1.900 betroffenen oder gemeldeten Paketen beziehungsweise Paketänderungen.
Das ist viel.
Das ist ernst.
Das sollte niemand kleinreden.
Aber jetzt kommt der Teil, der in der Panik gerne untergeht.
Das AUR ist riesig.
Wir reden nicht über ein kleines Nebenregal mit zwölf Paketen und einem vergessenen Theme aus 2009.
Wir reden über eine sechsstellige Menge an Paketbeschreibungen, Build-Rezepten und Community-Einträgen. Über 100.000 Pakete. Dazu tausende verwaiste Pakete, also Pakete ohne aktiven Maintainer.
Wenn in so einem System später über 1.900 Pakete oder Paketänderungen als betroffen gemeldet werden, ist das ein massiver Vorfall.
Aber es ist nicht dasselbe wie:
„Arch Linux ist komplett kompromittiert.“
Und es ist erst recht nicht dasselbe wie:
„Jedes AUR-Paket ist jetzt Malware und wer Arch nutzt, muss sein Mainboard in Weihwasser tauchen.“
Der Unterschied ist wichtig.
Der Vorfall betrifft das AUR, nicht die offiziellen Arch-Repositories. Wer betroffene AUR-Pakete gebaut oder aktualisiert hat, sollte das ernst nehmen. Da geht es nicht um gemütliches Zurücklehnen und Hoffen, dass der Pinguin schon aufpasst.
Aber aus „ein relevanter Teil des AUR wurde missbraucht“ wird in manchen Diskussionen sehr schnell:
„Arch ist unsicher.“
„Linux ist unsicher.“
„Open Source ist unsicher.“
„Alles brennt.“
Nein.
Das ist Panik-Theater.
Der Vorfall ist groß genug, um ihn ernst zu nehmen. Aber nicht groß genug, um jedes Verhältnis aus dem Fenster zu werfen und danach noch eine brennende Tastatur hinterherzuwerfen.
Das AUR ist nicht harmlos, nur weil prozentual ein kleiner Teil betroffen war.
Aber das AUR ist auch nicht vollständig verseucht, nur weil ein Teil betroffen war.
Die Wahrheit ist unbequemer:
Das Risiko war immer Teil des Modells.
Jetzt war es nur plötzlich sichtbar.
Und genau diese Sichtbarkeit trifft viele härter als der eigentliche technische Ablauf.
Die eigentliche Überraschung ist, dass manche überrascht sind
Was mich an der ganzen Diskussion fast genauso beschäftigt wie der Angriff selbst, ist diese plötzliche Offenbarung bei manchen Nutzern.
„Wie, das AUR kann gefährlich sein?“
Ja.
Das konnte es vorher auch.
Nur war es bequemer, nicht daran zu denken.
Das AUR war nie sicher im Sinne eines offiziellen, geprüften Repositories. Es war nie die Stelle, an der Arch sagt: „Hier, das haben wir gebaut, geprüft, signiert, ausgeliefert und als Teil unserer offiziellen Paketbasis verantwortet.“
Das AUR war immer:
„Hier liegen von Nutzern gepflegte Bauanleitungen. Du kannst sie verwenden. Aber du solltest verstehen, was du da tust.“
Das ist keine neue Information.
Das ist kein verlorenes Kapitel aus dem ArchWiki, das erst nach drei Vollmonden in einem versteckten Terminal-Menü erscheint.
Das stand die ganze Zeit auf dem Schild.
Nur haben viele eben nicht auf das Schild geschaut, weil dahinter das große AUR-Buffet stand.
Und dieses Buffet sah gut aus.
Sehr gut sogar.
Da gab es alles.
Browser-Betas. Git-Versionen. Proprietäre Tools. Alte Programme. Neue Programme. Exotische Programme. Dinge, deren Namen klingen, als hätte ein Passwortgenerator kurz Schluckauf gehabt. Tools, die man einmal für ein Problem brauchte und danach nie wieder.
Und dann kam der Reflex:
Enter.
Bestätigen.
Weiter.
Noch ein Paket.
Noch ein Tool.
Noch eine Abhängigkeit.
All you can eat.
Nur dass bei diesem Buffet niemand am Eingang gesagt hat:
„Keine Sorge, alles wurde von Arch offiziell geprüft, vorgekostet und mit einem kleinen Sicherheitshäubchen versehen.“
Da stand eher:
„Hier kocht die Community. Bitte guck wenigstens kurz in den Topf, bevor du dir den Teller vollmachst.“
Und einige sind trotzdem mit verbundenen Augen zum dritten Teller gerannt.
Ein PKGBUILD ist keine Magie
Das AUR ist kein offizielles Repository.
Es ist eine Sammlung von Paketbau-Anleitungen.
Diese Anleitungen heißen PKGBUILDs.
Ein PKGBUILD sagt dem System im Grunde:
„Hol diese Quellen, prüfe optional diese Prüfsummen, führe diese Befehle aus, baue daraus ein Paket und installiere es anschließend mit pacman.“
Und jetzt kommt der Punkt, den man eigentlich mit Neonmarker an die Wand schreiben müsste:
Ein PKGBUILD ist Shell-Code.
Nicht Zauberei.
Nicht Paketmagie.
Nicht „pacman, aber mit extra Glitzer“.
Shell-Code.
Und Shell-Code aus dem Internet ist eine Vertrauensentscheidung.
Wenn ein PKGBUILD oder eine Install-Datei Dinge nachlädt, Befehle ausführt, Pfade verändert, Services anlegt oder fremde Paketmanager wie npm oder Bun ins Spiel bringt, dann passiert da nicht einfach „Installation“.
Da wird Code ausgeführt.
Das ist der Unterschied zwischen:
„Ich installiere ein Paket aus einem offiziellen Repository, das in die normale Distributions-Infrastruktur eingebunden ist.“
und:
„Ich lasse eine Bauanleitung aus der Community Befehle auf meinem System ausführen und hoffe, dass sie sauber ist.“
Das kann völlig harmlos sein.
Das kann großartig sein.
Das kann genau das sein, was man braucht.
Aber es ist nicht dasselbe.
Und wer diesen Unterschied ignoriert, nutzt das AUR nicht mutig.
Er nutzt es blind.
Das ist kein Heldentum.
Das ist Terminal-Roulette mit hübscher Prompt-Farbe.
AUR-Helper machen es bequem. Vielleicht zu bequem.
Ein Teil des Problems ist die Bequemlichkeit.
AUR-Helper wie yay oder paru sind praktisch. Sehr praktisch sogar.
Sie machen die Nutzung des AUR angenehm. Suchen, bauen, installieren, aktualisieren. Alles fühlt sich schön integriert an.
Und genau da liegt die Falle.
Denn je bequemer etwas wird, desto mehr vergisst man, was darunter passiert.
Aus:
„Ich lade eine fremde Build-Anleitung herunter, prüfe sie, baue daraus lokal ein Paket und installiere es.“
wird im Kopf:
„Ich installiere halt ein Paket.“
Und aus:
„Dieser Diff zeigt mir, dass beim Update plötzlich ein neues Install-Script und eine npm-Abhängigkeit dazugekommen sind.“
wird:
„Jaja, weiter, ich wollte nur kurz updaten.“
Das ist der Moment, in dem das AUR vom Werkzeug zum Futtertrog wird.
Und ja, da muss man den Ellenbogen ausfahren:
Wer das AUR jahrelang als „geil, da gibt es alles“-Supermarkt benutzt hat, ohne PKGBUILDs zu lesen, ohne Diffs zu prüfen, ohne Maintainer-Wechsel zu beachten und ohne sich zu fragen, warum ein Paket plötzlich npm-Kram nachlädt, der darf jetzt verunsichert sein.
Aber überrascht?
Nein.
Überrascht ist zu bequem.
Das ist wie jahrelang jedes curl | sh aus irgendeinem GitHub-README zu kopieren, weil es bisher gut ging, und dann beim ersten Brandgeruch zu fragen:
„Seit wann kann sowas gefährlich sein?“
Bruder.
Da stand schon immer fremder Code mit Streichhölzern.
Das AUR ist nicht böse
Das AUR ist nicht böse.
Das AUR ist auch nicht „kaputt“, nur weil sein Vertrauensmodell gerade schmerzhaft sichtbar wurde.
Das AUR ist ein mächtiges Community-Werkzeug.
Und mächtige Werkzeuge haben eine unangenehme Eigenschaft:
Sie können nützlich sein.
Oder dir sehr elegant den Daumen kürzen.
Das AUR gibt Nutzern Zugriff auf eine riesige Menge Software. Es ist einer der Gründe, warum Arch und Arch-basierte Systeme so attraktiv sind. Man findet dort oft genau das Paket, das sonst nirgends sauber verfügbar ist.
Aber dieses „alles ist verfügbar“-Gefühl hat einen Preis.
Der Preis ist Aufmerksamkeit.
Nicht Panik.
Nicht Paranoia.
Aufmerksamkeit.
Das bedeutet:
PKGBUILDs lesen.
Diffs bei Updates anschauen.
Bei neuen Maintainer-Namen kurz wach werden.
Bei verwaisten Paketen besonders vorsichtig sein.
Bei neuen Install-Hooks nicht automatisch Enter drücken.
Bei npm, Bun, curl, wget und fremden Binärdateien nicht sofort mental auschecken.
Gerade bei verwaisten Paketen sollte die Augenbraue automatisch hochgehen.
Nicht jeder neue Maintainer ist böse.
Natürlich nicht.
Viele übernehmen Pakete aus guten Gründen. Sie pflegen Software weiter, räumen auf, machen Dinge wieder nutzbar. Ohne solche Leute wäre das AUR deutlich ärmer.
Aber „Paket war verwaist und wurde gerade übernommen“ ist trotzdem ein Moment zum Hinschauen.
Nicht zum Wegklicken.
Nicht zum „wird schon passen“.
Nicht zum „ich habe Feierabend, bitte keine Denkaufgaben mehr“.
Genau dort greifen solche Angriffe an.
Nicht an einer magischen Kernel-Schwachstelle.
Nicht an einem Hollywood-Hack mit grünen Zahlen.
Sondern an Gewohnheit.
An Vertrauen.
An Müdigkeit.
An der Tatsache, dass viele Nutzer bei AUR-Updates geistig schon auf dem Sofa liegen.
Das Problem heißt nicht Arch. Das Problem heißt Fremdquelle.
Damit hier niemand den falschen Film schaut:
Das ist kein „Arch schlecht, andere gut“-Artikel.
Wer jetzt im Debian-Gewand auf einem Hügel steht und ruft „Seht ihr, deshalb nur stabile Repos!“, sollte kurz prüfen, ob irgendwo ein fremdes Repository, ein manuell installiertes .deb, ein curl-Script, ein Docker-Image oder ein npm-Paket im Keller liegt.
Spoiler:
Sehr wahrscheinlich ja.
Fremdquellen gibt es überall.
Ubuntu hat PPAs.
Fedora hat COPR.
openSUSE hat OBS und Home-Repositories.
Debian-Nutzer können Drittanbieter-Repositories einbinden.
Man kann AppImages herunterladen, GitHub-Releases ausführen, Docker-Container ziehen, Python-Pakete installieren, npm-Projekte bauen und sich mit einem einzigen curl | sh den digitalen Teppich unter den Füßen anzünden.
Überall gilt dieselbe Grundregel:
Sobald Software außerhalb der offiziellen, gepflegten Paketquellen kommt, verschiebt sich Verantwortung zum Nutzer.
Der Unterschied ist eher die Kultur.
Beim AUR ist dieses Fremdquellen-Gefühl besonders gut getarnt, weil es so tief zum Arch-Alltag gehört. Viele Arch-Nutzer sprechen über das AUR wie über einen Supermarkt:
„Gibt es im AUR.“
Das klingt harmlos.
Das klingt bequem.
Das klingt wie:
„Liegt im Regal 7, direkt neben den Nudeln.“
Aber eigentlich müsste es heißen:
„Es gibt eine von irgendwem gepflegte Bauanleitung, die beim Erstellen des Pakets Code auf deinem System ausführt.“
Nur sagt das niemand so, weil es natürlich deutlich weniger sexy klingt.
„Gibt es im AUR“ ist der Linux-Satz für:
„Da ist eine Abkürzung. Vielleicht ist sie sauber. Vielleicht steht dort ein Kobold mit Root-Rechten.“
Das Muster ist nicht neu
Der aktuelle Vorfall ist nicht der erste Hinweis darauf, dass Software-Lieferketten angreifbar sind.
Auch im AUR gab es früher schon Fälle.
2018 wurde zum Beispiel das verwaiste AUR-Paket acroread kompromittiert. Ein neuer Maintainer übernahm das Paket und baute eine verdächtige Schadcode-Kette ein. Damals wurden auch weitere Pakete im Zusammenhang mit Malware genannt.
Das Muster war schon damals ziemlich deutlich:
Verwaistes Paket.
Neue Übernahme.
Geänderte Installationslogik.
Nutzer, die beim Bauen Code ausführen.
Kommt einem bekannt vor?
Ja.
Weil es bekannt ist.
Auch 2025 gab es Berichte über Malware in AUR-Paketen, unter anderem im Zusammenhang mit einem Remote-Access-Trojaner. Wieder ging es nicht darum, dass offizielle Arch-Repositories plötzlich schlecht wurden. Es ging um Community-Pakete, Vertrauen und die Frage, wer eigentlich hinschaut, wenn irgendwo ein Paket auftaucht, das zu bequem aussieht, um wahr zu sein.
Und außerhalb des AUR gab es den großen XZ-Fall 2024.
Das war nochmal eine andere Liga. Dort ging es nicht um ein Community-Paket im AUR, sondern um eine langfristig vorbereitete Supply-Chain-Attacke auf xz/liblzma. Vertrauen wurde über längere Zeit aufgebaut, bis manipulierte Versionen veröffentlicht wurden. Entdeckt wurde die Backdoor durch Andres Freund, weil ihm ungewöhnliches Verhalten bei SSH auffiel.
Das war kein „jemand hat schnell ein Paket übernommen und Müll reingeschrieben“.
Das war eher:
„Jemand hat über längere Zeit Vertrauen aufgebaut, Druck erzeugt, Zugang gewonnen und dann eine Bombe in die Lieferkette gelegt.“
Der AUR-Vorfall und XZ sind nicht identisch.
Aber sie gehören zur selben Familie von Problemen:
Software entsteht nicht im luftleeren Raum.
Vertrauen ist Teil der Infrastruktur.
Maintainer sind Menschen.
Pakete können übernommen werden.
Abhängigkeiten können missbraucht werden.
Und Paketmanager führen am Ende Dinge aus, die vorher irgendjemand geschrieben hat.
Manchmal grob.
Manchmal raffiniert.
Manchmal durch verwaiste Pakete.
Manchmal durch jahrelangen sozialen Druck und schleichende Maintainer-Übernahme.
Und manchmal reicht es, dass genug Leute einfach nicht hinsehen.
Die unbequeme Lektion
Die bequeme Lektion wäre:
„Nie wieder AUR.“
Das ist zu simpel.
Die andere bequeme Lektion wäre:
„Alles halb so wild, einfach weiter Enter drücken.“
Das ist dumm.
Die unbequeme Lektion liegt dazwischen:
Nutze das AUR, aber benutze dabei dein Gehirn.
Erwachsene Nutzung heißt nicht, jedes PKGBUILD wie ein hauptberuflicher Security-Auditor zu zerlegen.
Aber es heißt, nicht blind alles durchzuwinken.
Es heißt, bei neuen Abhängigkeiten hinzuschauen.
Es heißt, bei Maintainer-Wechseln aufmerksam zu werden.
Es heißt, bei npm, Bun, curl, wget, obskuren Binärdownloads und Install-Hooks nicht nur müde „jaja“ zu murmeln.
Es heißt, AUR-Helper nicht mit offiziellen Paketmanagern zu verwechseln.
Und es heißt auch, sich nicht erst dann über Risiken zu empören, wenn sie laut genug sind, um durch die eigene Bequemlichkeitsdecke zu dringen.
Denn genau das ist der Punkt:
Viele waren nicht uninformiert, weil die Information fehlte.
Viele waren uninformiert, weil die Information störte.
Das ist härter.
Aber wahrscheinlich näher an der Wahrheit.
Das Buffet ohne Küchenaufsicht
Das AUR war für viele Nutzer ein All-you-can-eat-Buffet.
Ein riesiger Tisch voller Pakete.
Man geht hin, nimmt sich Chrome, Discord-Builds, exotische Tools, alte Programme, neue Git-Versionen, irgendwelche CLI-Helferlein, ein Theme, drei Applets und ein Programm, dessen Beschreibung klingt wie ein Nebenquest-Gegenstand aus einem kaputten JRPG.
Und dann wundert man sich, dass bei einem Buffet ohne Küchenaufsicht irgendwann jemand die Mayonnaise in der Sonne stehen lässt.
Das ist nicht gegen Arch gerichtet.
Das ist gegen Gedankenlosigkeit gerichtet.
Arch ist eine Distribution, die traditionell sehr viel Eigenverantwortung voraussetzt. Das ist kein Fehler. Das ist Teil des Modells.
Aber dann muss man diese Eigenverantwortung auch tragen.
Man kann nicht gleichzeitig sagen:
„Ich nutze Arch, weil ich Kontrolle und Freiheit will.“
und sich dann bei jedem AUR-Update verhalten wie:
„Bitte füttere mich, Paketroboter, ich möchte nicht wissen, was auf dem Löffel ist.“
Das passt nicht zusammen.
Das ist wie ein Motorrad kaufen, weil man Freiheit liebt, und sich dann beschweren, dass es keine Seitenairbags wie ein Familienvan hat.
Was Nutzer jetzt tun sollten
Keine Panik.
Aber auch kein Schulterzucken.
Wer Arch oder ein Arch-basiertes System nutzt und AUR-Pakete installiert hat, sollte seine Fremdpakete prüfen.
Zum Beispiel mit:
pacman -QmDas zeigt lokal installierte Pakete, die nicht aus den offiziellen Repositories stammen.
Danach sollte man sich ein paar Fragen stellen:
Welche dieser Pakete brauche ich wirklich?
Welche wurden kürzlich aktualisiert?
Welche davon sind verwaist oder wurden kürzlich übernommen?
Welche haben neue Install-Dateien, Hooks oder fremde Paketmanager wie npm oder Bun in ihren Build-Anweisungen?
Welche Pakete tauchen in bekannten Listen betroffener AUR-Pakete auf?
Wenn ein betroffener Build ausgeführt wurde, reicht „Paket entfernen“ unter Umständen nicht.
Denn wenn Schadcode bereits lief, ist das nicht mehr nur Paketverwaltung. Dann geht es um Systemvertrauen.
Je nachdem, was passiert ist, kann das bedeuten:
Betroffene Pakete entfernen.
Cache und Build-Verzeichnisse prüfen.
Passwörter und Tokens ändern.
SSH-Keys, GitHub-Tokens, npm-Tokens, Cloud-Zugänge und ähnliche Geheimnisse prüfen.
Logs anschauen.
Und im Zweifel ein System neu aufsetzen, statt sich selbst mit Wunschdenken zu beruhigen.
Ja, das ist nervig.
Sicherheit ist oft nervig.
Deshalb wird sie so gerne ignoriert, bis sie plötzlich sehr laut vor der Tür steht und fragt, ob man kurz über npm sprechen könne.
Das AUR bleibt mächtig. Aber es bleibt AUR.
Der aktuelle AUR-Vorfall ist ernst.
Er ist groß genug, um ihn nicht wegzulächeln.
Er ist aber nicht groß genug, um jede Verhältnismäßigkeit aus dem Fenster zu werfen.
Nicht ganz Arch ist abgebrannt.
Nicht jedes AUR-Paket ist Malware.
Nicht jeder AUR-Nutzer muss jetzt mit Alufolie um den Router tanzen.
Aber wer das AUR jahrelang blind als Paket-Buffet genutzt hat, sollte vielleicht nicht so tun, als wäre diese Erkenntnis neu vom Himmel gefallen.
Das AUR war nie ein App-Store.
Es war nie ein offizielles Repository.
Es war nie ein Sicherheitsversprechen.
Es war immer ein Community-Werkzeug.
Mächtig.
Praktisch.
Offen.
Chaotisch.
Und genau deshalb mit Vorsicht zu genießen.
Man kann das AUR weiter nutzen.
Man sollte es nur nicht mehr wie einen Selbstbedienungsladen behandeln, in dem jede Schale am Buffet automatisch vom Arch-Sicherheitskoch vorgekostet wurde.
Denn manchmal steht da eben nicht „Paket“.
Manchmal steht da nur:
„Fremder Code möchte kurz mit Root-Rechten in deine Küche.“
Und wer dann trotzdem mit verbundenen Augen zugreift, darf sich am Ende nicht beschweren, wenn der Nachtisch Root-Rechte hatte.