AUR oder Flatpak

Ditana unterstützt native Arch-Pakete, lokal mit paru gebaute AUR-Pakete und Flatpak-Anwendungen von Flathub, die in einer Sandbox laufen. Die Rangfolge lautet zuerst nativ, danach Flatpak, dann das AUR – und der Grund, von einem nativen Paket abzuweichen, ist nie, dass Flatpak ein besseres Erlebnis bietet, sondern dass kein natives Paket verfügbar ist.

Wann Flatpak die bessere Wahl ist

Wenn Arch selbst ein Paket nicht anbietet, ziehen Sie für eine Desktop-Anwendung, für die ein gepflegter Flathub-Build existiert, Flatpak dem AUR vor.

• Sandbox-Isolierung. Flatpak-Anwendungen laufen in einer Sandbox von bubblewrap mit eingeschränktem Zugriff auf das Dateisystem und auf IPC. Für Browser, Medienplayer und andere Software, die mit dem Internet in Berührung kommt, ist das eine echte zusätzliche Schutzschicht im Sinne einer gestaffelten Verteidigung.
• Keine Build-Zeit. Aus dem Quellcode gebaute AUR-Pakete können Minuten brauchen (oder Stunden, bei grossen Anwendungen wie LibreOffice). Bei Flatpak werden bereits kompilierte Binärdateien von Flathub heruntergeladen.
• Kein ABI-Risiko. Binäre AUR-Pakete funktionieren gelegentlich nicht mehr, wenn Systembibliotheken aktualisiert werden und die Binärdatei des Upstream-Projekts eine andere ABI erwartet. Flatpaks bringen ihre Laufzeitumgebung mit und sind gegen dieses Risiko abgeschirmt.
• Vorhersehbare Aktualisierungen. Flathub-Veröffentlichungen tragen Versionsnummern und lassen sich leicht auf eine frühere Version zurücksetzen. Das AUR wird laufend aktualisiert und ist unkoordiniert.

Wann das AUR die bessere Wahl ist

Es gibt drei Fälle, in denen Ditana das AUR gegenüber Flatpak bevorzugt – oder sogar voraussetzt.

Ditana baut und signiert bereits 45 der benötigten AUR-Rezepte selbst neu, sodass paru -S sie oft aus der Ditana-Paketquelle statt aus dem AUR bezieht. Jedes davon wurde vor dem Bauen eingestuft: Eine Änderung an einer Quell-URL, an einer Build-Funktion oder an einer Prüfsumme ohne neue Version hält den gesamten Durchlauf an, damit sich eine Person die Sache ansieht. Rezepte, die Ditana nicht führt, installiert paru direkt aus dem AUR, ungeprüft – und um genau diesen Unterschied geht es im Rest dieser Seite.

Browser auf Chromium-Basis unter Ditanas Standardhärtung

Ditana gibt unprivilegierte Benutzer-Namensräume (user namespaces) nicht jedem Programm frei. Sie bildeten die Grundlage mehrerer veröffentlichter lokaler Rechteausweitungen, und von den sechzehn Einträgen zum Linux-Kernel im Katalog bekannter ausgenutzter Schwachstellen der CISA aus drei Jahren sind sechs über sie ausnutzbar – gezählt anhand der Version 2026.09.04 des Katalogs; welche sechs es sind, ist unsere Lesart, es lohnt sich also, das nachzuprüfen, statt es zu glauben. Ditana erlaubt sie daher für jedes Programm einzeln: Ein minimales BPF-Programm, das an den Hook userns_create des Kernels selbst angehängt ist, verweigert jeder ausführbaren Datei einen Namensraum, sofern keine Einstellung ihn für sie angefordert hat. Für bwrap wurde er angefordert, daher baut jedes Flatpak seine äussere Sandbox wie gewohnt auf.

Brave kommt dennoch als brave-bin aus dem AUR, und zwar aus zwei Gründen, die mit der äusseren Sandbox nichts zu tun haben. Sein Flatpak enthält zypak, das tief in der Sandbox mit einer eigenen Binärdatei zusätzliche Namensräume anlegt, und ob sich eine Positivliste pro ausführbarer Datei überhaupt auf diese erstreckt, ist ungetestet. Ausserdem wird eine ausführbare Datei innerhalb eines Flatpaks durch flatpak update ersetzt, was der Hook, der die Positivliste synchron hält, nicht mitbekommt; die Berechtigung würde also bei der nächsten Aktualisierung stillschweigend verfallen.

Das AUR-Paket brave-bin braucht nichts davon. Es bringt seinen eigenen setuid-Helfer chrome-sandbox mit und baut seine Sandbox ganz ohne Benutzer-Namensraum auf – deshalb wird es beibehalten, obwohl die Regel Flatpak vor das AUR stellt.

Wenn einer selbst installierten Sandbox ein Benutzer-Namensraum verweigert wird

Wenn einer Sandbox, die Sie selbst installiert haben, ein Benutzer-Namensraum verweigert wird, dann hat der Wächter ihn verweigert. Tragen Sie die ausführbare Datei in /etc/ditana/userns-allow.conf ein, einen absoluten Pfad pro Zeile, und laden Sie den Wächter neu:

sudo ditana-userns-guard --reload

sudo ditana-userns-guard --status zeigt, wie viele Namensräume seit dem Laden des Wächters erlaubt und verweigert wurden, und listet die Programme auf, denen er einen verweigert hat, die jüngsten zuerst, jeweils mit dem Benutzerkonto, unter dem sie liefen, und der Häufigkeit. sudo ditana-userns-guard --observe hört auf zu verweigern und führt die Liste weiter; so zeigt er, was ein Programm anfordern würde, während das Programm weiterhin läuft. sudo ditana-userns-guard schaltet das Verweigern wieder ein.

Software, die es auf Flathub nicht gibt

Ein nicht unerheblicher Teil nützlicher Linux-Software existiert nur im AUR – spezialisierte Entwicklerwerkzeuge, herstellerspezifische Treiber, Hardware-Dienstprogramme, Schriftarten. Dafür ist das AUR die einzige Option, und paru macht ihre Installation einfach.

Wenn Sie am AUR-Ökosystem teilnehmen möchten

Wenn Sie Arch verwenden und die Commit-Feeds des AUR verfolgen, Stimmen abgeben oder eigene AUR-Pakete betreuen möchten, bleiben Sie eingebunden, wenn Sie auch für Ihre alltäglichen Anwendungen beim AUR bleiben.

Wie Ditana bei der Installation entscheidet

In der KDL-Konfiguration kann jede Einstellung arch-packages, flatpak-packages und aur-packages nebeneinander angeben, dazu userns-allow für eine ausführbare Datei, deren Sandbox einen Benutzer-Namensraum braucht. Wenn mehr als eine Quelle verfügbar ist, wird bewusst entschieden, Paket für Paket, und die Begründung wird in der jeweiligen Datei vom Typ .kdl festgehalten. Sehen Sie sich ditana-config an, um die Überlegungen im Zusammenhang zu lesen.

Praxistipp: installierte Flatpaks regelmässig prüfen

Flatpak-Laufzeitumgebungen sammeln sich an. Führen Sie gelegentlich sudo flatpak uninstall --unused aus, um Speicherplatz freizugeben – und sudo flatpak update, um die Anwendungen aktuell zu halten. Beide Vorgänge sind unbedenklich. Ditana installiert Flatpaks in die Installation für das ganze System statt in eine Installation pro Benutzerkonto; deshalb brauchen beide Befehle Root-Rechte.