Versionshinweise zu 0.9.4 Beta
Veröffentlichungsdatum: 12. September 2026
Vorherige Version: 0.9.3 Beta (21. Mai 2026)
Unprivilegierte Benutzer-Namensräume: eingeschränkt, nicht ausgeschaltet
Abschnitt «Unprivilegierte Benutzer-Namensräume: eingeschränkt, nicht ausgeschaltet»Arch hat bubblewrap-suid im September 2026 entfernt. Ditana hatte sich darauf gestützt, um Sandboxes funktionsfähig zu halten, während unprivilegierte Benutzer-Namensräume (user namespaces) ausgeschaltet blieben; deshalb legte die Entfernung beide Hälften dieses Aufbaus gleichzeitig lahm – und weil das Installationsprogramm seine Konfiguration zur Laufzeit lädt, liess sie auch Installationen vom bereits veröffentlichten Medium der Version 0.9.3 scheitern und nicht nur neu erstellte.
Es gab keinen Ersatz, zu dem Ditana hätte wechseln können. Das Upstream-Projekt entfernte die setuid-Unterstützung in bubblewrap 0.12.0, einen Tag nachdem Version 0.11.2 CVE-2026-41163 behoben hatte, eine Rechteausweitung, die ausschliesslich in diesem Modus bestand, und den Zweig 0.11.x, der für alle bereitgestellt wurde, die ihn noch brauchten, hat nie jemand übernommen.
Deshalb ist die Anordnung jetzt umgekehrt. Statt Benutzer-Namensräume für alle zu deaktivieren und eine einzige Binärdatei davon auszunehmen, erlaubt Ditana sie pro ausführbarer Datei. Ein BPF-Programm, das an den Hook userns_create des Kernels angehängt ist, verweigert allem, was nicht deklariert wurde, einen Namensraum, und die Deklaration steht in der Konfiguration neben dem Paket, das sie braucht:
- name="flatpak" default-value=#true { arch-packages "flatpak" userns-allow "/usr/bin/bwrap" }Ein wesentlicher Punkt, weil er bestimmt, was im Fehlerfall geschieht: Ein Hook dieser Art kann immer nur verweigern, nie gewähren. Die sysctl-Einstellung, die Benutzer-Namensräume bisher deaktiviert hat, muss erhöht werden, damit der Wächter überhaupt etwas hat, worauf er einwirken kann, und erhöht wird sie nur von dem Dienst, der das Programm bereits geladen und angehängt hat. Ein Rechner, der es nicht laden kann, lässt Benutzer-Namensräume vollständig ausgeschaltet. Ein solcher Fehler kostet Sie Ihre Sandboxes, aber nie Ihren Schutz.
Der Wächter ist ein eigenes Paket, ditana-userns-guard, das zusammen mit der Option System Hardening installiert wird, die früher «Disable unprivileged user namespaces» hiess.
LibreWolf kommt jetzt von Arch
Abschnitt «LibreWolf kommt jetzt von Arch»LibreWolf stammt jetzt aus den Paketquellen von Arch statt von Flathub, gemäss der Rangfolge, die ein natives Paket an die erste Stelle setzt. Brave ist weiterhin über das AUR erhältlich; die Begründung steht ausführlich auf der Seite AUR oder Flatpak.
Jeder sysctl-Wert wird als Daten deklariert
Abschnitt «Jeder sysctl-Wert wird als Daten deklariert»Jeder sysctl-Wert, den das Installationsprogramm schreibt, wird jetzt als Daten deklariert, statt als Shell-Text zusammengesetzt zu werden. Zwei Einstellungen, die denselben Schlüssel mit unterschiedlichen Werten schreiben, stoppen die Installation und werden beide genannt. Bisher wurden beide Zeilen geschrieben, und die letzte setzte sich stillschweigend durch.
Unbeaufsichtigte Installation
Abschnitt «Unbeaufsichtigte Installation»Eine Installation kann jetzt laufen, ohne dass jemand an der Tastatur sitzt. Eine Antwortdatei liefert im Voraus, was das Installationsprogramm sonst abfragen würde, und sie liegt auf einem kleinen Konfigurationslaufwerk, das das Installationsprogramm selbstständig findet – genau derselbe Aufbau, den ein Hosting-Anbieter verwenden würde, um Ditana über PXE einzurichten. Nirgends werden Tastenanschläge simuliert: Der Mechanismus besteht darin, dass das Installationsprogramm seine Antworten liest, statt sie zu erfragen; deshalb funktioniert er für einen Anbieter und nicht nur für einen Test.
Das Passwort des Benutzerkontos wird der Antwortdatei als Hash entnommen, nie im Klartext. Eine Beispieldatei liegt im Repository des Installationsprogramms, und der Mechanismus ist dort vollständig dokumentiert.
Eine Antwort, die nicht wirksam werden kann, stoppt die Installation, statt stillschweigend verworfen zu werden: Eine Einstellung, die dieser Rechner nicht anbietet, und eine, die ein Ausdruck für den Standardwert wieder überschreiben würde, werden beide unter Angabe ihres Namens verweigert, zusammen mit der Bedingung, die sie unmöglich macht. Und weil niemand auf den Bildschirm schaut, schreibt ein Durchlauf, der anhält, seine Ursache auf die erste serielle Schnittstelle, jede Zeile mit der Markierung DITANA-AUTOINSTALL-ABORT:, damit ein Bereitstellungssystem, das die Konsole liest, den Grund erfährt, solange der Rechner noch läuft, statt eine Stille auszusitzen. Liegt die Konsole anderswo, nennt die Kernel-Befehlszeile sie.
Das verwendet Ditana auch für sich selbst. Jede Nacht installiert der Build-Host die Paketquelle, die er soeben gebaut hat, unbeaufsichtigt in eine virtuelle Maschine, und die Pakete werden nur veröffentlicht, wenn das installierte System startet und von sich aus antwortet.
Siehe docs/unattended-installation.md.
ZFS auf dem Installationsmedium
Abschnitt «ZFS auf dem Installationsmedium»Das Live-Medium startete einen Kernel ohne ZFS-Modul, sodass eine ZFS-Installation auf Hardware fehlschlug, auf der sie zuvor gelungen war. Die ZFS-Pakete werden jetzt über pacstrap geliefert, und das initramfs wird danach neu gebaut; zfsbootmenu wird von dem dafür zuständigen Hook hinzugefügt statt über einen zweiten Weg, der damit in Konflikt geraten könnte. Der Ausweich-Bootpfad für UEFI war falsch und wurde korrigiert.
Die Druckerunterstützung ist vollständig. mDNS ist in firewalld freigegeben und avahi-daemon ist aktiviert, sodass ein Netzwerkdrucker gefunden wird, statt eingetippt zu werden.
Hardware
Abschnitt «Hardware»Auf manchen Rechnern lässt die Firmware den Prozessor nach einem Wechsel in den Bereitschaftsmodus in seinem flachsten Leerlaufzustand verharren, was Strom kostet, solange der Rechner läuft. Ditana erkennt das jetzt und umgeht es.
Eine neue Option bindet ARP-Antworten an die Schnittstelle, die die Anfrage empfangen hat. Auf einem Rechner mit mehr als einer Schnittstelle im selben Subnetz antwortet der Kernel sonst über eine beliebige davon, was Switches und manche Konfigurationen mit Lastverteilung durcheinanderbringt.
Die Grafikerkennung fragt jetzt ab, ob die GPU unter Wayland funktioniert, statt ob sie irgendetwas beschleunigt; das ist die Frage, von der die Auswahlmöglichkeiten beim Desktop tatsächlich abhängen.
Arbeitsspeicher
Abschnitt «Arbeitsspeicher»Die Option Extended ZRAM Overcommit erhöht die virtuelle Grösse des komprimierten Swaps im Arbeitsspeicher von 100 % auf 175 % des physischen Arbeitsspeichers und den Kompressionsaufwand von zstd von Stufe 3 auf Stufe 6, sodass ein Rechner ungefähr das 1,75-Fache seines Arbeitsspeichers in komprimierter Form hält, bevor er die Swap-Partition auf dem Datenträger anrührt. Die Latenz beim Einlagern von Speicherseiten bleibt gleich, weil zstd unabhängig vom Aufwand der Stufe gleich schnell dekomprimiert. Die Voreinstellung bleibt unverändert.
Das Installationsmedium selbst
Abschnitt «Das Installationsmedium selbst»Das ISO wird mit archiso 90 erstellt. Das Paket b43-firmware wurde daraus entfernt: Es zog neben dem Kernel, den Ditana startet, auch den Mainline-Kernel auf das Medium. Der Build-Vorgang wurde verschärft – nichts, was auf das Medium kopiert wird, kann jetzt noch einem symbolischen Link zurück ins Live-System folgen, die Berechtigungen dessen, was darauf abgelegt wird, sind deklariert statt geerbt, und mehrere Gigabyte an Zwischendateien liegen auf einem Datenträger statt in einem tmpfs.
Das Medium enthält den versionierten Stand und nichts sonst: Eine Datei, die im Arbeitsverzeichnis liegt und die keine Regel des Repositorys deklariert, stoppt einen signierten Build, denn alles unterhalb des airootfs des Profils gelangt in das Abbild. Das installierte System hält dann seine Herkunft fest, als BUILD_ID und VERSION_CODENAME in /usr/lib/os-release: welches Medium es erstellt hat und welchen Konfigurationsstand dieses Medium enthielt.
Builds, die Sie prüfen können
Abschnitt «Builds, die Sie prüfen können»Jedes Paket, das Ditana ausliefert, wird aus seinem Upstream-Rezept neu gebaut, signiert und nur als vollständiger Satz veröffentlicht: Wenn sich ein Paket nicht bauen lässt oder seine Quellen nicht überprüft werden können, wird überhaupt nichts veröffentlicht. Seit 0.9.3 ist dieser Vorgang sichtbar. Jeder Durchlauf wird aufgezeichnet und öffentlich gemacht, auch die Durchläufe, bei denen nichts ausgeliefert wurde, und jedes neu gebaute Paket verlinkt das Protokoll seines eigenen Builds.
Seither sind zwei Dinge hinzugekommen. Jede Änderung, die ein Upstream-Rezept einführt, wird eingestuft, bevor irgendetwas gebaut wird, und alles, was nicht schon durch seine Bauart sicher ist, hält den ganzen Durchlauf an, damit ein Mensch es prüft – das AUR steht unter einem aktiven Angriff auf die Lieferkette, und Ditana baut AUR-Rezepte für eine Paketquelle neu, der ihre Benutzerinnen und Benutzer über die Signatur-Konfiguration von pacman vertrauen. Und eine Paketquelle, die sich ohne Probleme bauen und signieren lässt, kann trotzdem eine sein, aus der niemand installieren kann; deshalb wird sie vor der Veröffentlichung in eine virtuelle Maschine installiert.
Die Pipeline, auf der all das beruht, ist jetzt ebenfalls öffentlich. Sie ist älter als Ditana: Sie begann etwa 2023 als einzelnes Shell-Skript und war nie für fremde Augen bestimmt. Sie wird veröffentlicht, weil die Aussagen der Build-Seite so viel wert sind wie ihre Belege, und sie ist Teil dieser Belege. Sie liegt unter github.com/acrion/ditana-build, und die Durchläufe, die sie aufzeichnet, stehen unter ditana.org/builds.
Pakete werden mit einem eigenen Signatur-Unterschlüssel statt mit dem Hauptschlüssel signiert. Ein Unterschlüssel lässt sich unabhängig widerrufen und ersetzen, und er kann keine weiteren Schlüssel zertifizieren. Sie müssen deswegen nichts tun: Der Schlüsselbund, der ihn enthält, wurde im August ausgeliefert und ist längst eingespielt.
Upgrade von 0.9.3
Abschnitt «Upgrade von 0.9.3»Installationen, die mit dem Medium der Version 0.9.3 erstellt wurden, funktionieren weiterhin, mit einem einzigen Fall, der von Hand gelöst werden muss. Das Paket bubblewrap-suid existiert nicht mehr, daher wird es bei der nächsten Systemaktualisierung ersetzt, und Flatpak und Bubblejail funktionieren auf einem Rechner, auf dem unprivilegierte Benutzer-Namensräume deaktiviert sind, nicht mehr. Brave und andere Anwendungen aus dem AUR sind nicht betroffen.
Abhilfe schafft der oben beschriebene Wächter:
sudo pacman -Syu ditana-userns-guardecho /usr/bin/bwrap | sudo tee /etc/ditana/userns-allow.confsudo systemctl enable --now ditana-userns-guard.serviceEin absoluter Pfad pro Zeile; # leitet einen Kommentar ein. Der Dienst verweigert das Erhöhen der sysctl-Einstellung, solange er das Programm nicht zuvor geladen und angehängt hat, sodass ein Rechner, auf dem er nicht laufen kann, genauso abgeriegelt bleibt, wie er war.
Ein älteres Medium kann überhaupt nicht mehr installieren. Das Installationsprogramm lädt seine Konfiguration, wenn es läuft, daher greift ein USB-Stick mit Version 0.9.3 nach Paketen, die seine eigene Paketquelle nicht mehr liefern kann, und bricht ab. Schreiben Sie das aktuelle Abbild darauf.
Eine Neuinstallation vom Medium der Version 0.9.4 braucht nichts davon.
Diese Übersetzung wurde maschinell erstellt. Leserinnen und Leser verbessern sie auf Weblate.