Als TUXEDO kürzlich ankündigte, TUXEDO OS künftig auf Debian Testing statt auf Ubuntu LTS aufzubauen, kam schnell eine berechtigte Frage auf: Wie soll das mit den Sicherheitsupdates funktionieren, da Debian Testing über keinen eigenen Security-Kanal wie Stable oder Unstable verfügt? In einem neuen Blogbeitrag erklärt TUXEDO jetzt, wie der Hersteller von Linux-Notebooks und -PCs das lösen will.
Wie Testing funktioniert
Der Knackpunkt liegt im Migrationsprozess von Debian Testing selbst: Pakete wandern aus Unstable (Sid) erst nach einer Mindestwartezeit von wenigen Tagen dorthin, und zwar nur, wenn sie in dieser Zeit keine veröffentlichungskritischen Bugs zeigen, alle Bauprozesse für die unterstützten Architekturen sauber durchlaufen und keine Paketkonflikte auftreten. In der Praxis können zwischen einem Sicherheitspatch in Unstable und dessen Ankunft in Testing zwei bis 14 Tage liegen. Für ein Desktop-System, das täglich produktiv genutzt wird, reicht das den TUXEDO-Entwicklern in Hinblick auf die Sicherheit nicht aus.
Deshalb betreibt TUXEDO eigene Paket-Repositories, in denen die Debian-Basis gespiegelt wird. Bleibt eine kritische Lücke länger offen als vertretbar, greift TUXEDO aktiv ein: Je nach Fall werden bereits gepatchte Pakete direkt aus Unstable übernommen oder eigene Backports gebaut und über die eigene Infrastruktur ausgeliefert, bevor der Fix regulär in Testing landet.
CVE-Monitoring
Grundlage dafür ist ein automatisiertes CVE-Monitoring, das derzeit aufgebaut wird und den Debian Security Tracker sowie weitere öffentliche Datenbanken auswertet. Werden neue Schwachstellen bekannt, gleicht TUXEDO deren Status mit dem eigenen Paketbestand ab und priorisiert entsprechend.
Bei besonders gravierenden Lücken, etwa in einer zentralen Komponente wie sudo, soll ein beschleunigter QA-Prozess dafür sorgen, dass funktionierende Fixes innerhalb weniger Stunden bereitstehen. TUXEDO betont hier den Architekturvorteil gegenüber der Ubuntu-Ära: Statt auf Canonicals Paketierung angewiesen zu sein, hat man jetzt selbst die Kontrolle über den kompletten Update-Prozess.
Btrfs und Snapper
Als Sicherheitsnetz kommt Btrfs in Kombination mit Snapper hinzu: Geht doch mal ein Update schief, lässt sich das System jederzeit auf einen funktionierenden Snapshot zurückrollen, was gerade für Einsteiger ein wichtiges Vertrauenspolster bei Updates und Konfigurationsänderungen darstellt. In den heiklen Phasen kurz vor einem neuen Debian-Stable-Release, dem sogenannten Freeze, beabsichtigt TUXEDO die manuellen Paketprüfungen zusätzlich hochzufahren, um wichtige Fixes gezielt an Migrationsblockaden vorbeizuschleusen.
Ein Punkt, der in der Debatte um Testing als Basis oft untergeht: Die Komponenten mit der größten Angriffsfläche im Alltag – Kernel, Browser sowie weitere wichtige Bestandteile des Basissystems – kommen bei TUXEDO OS ohnehin nicht direkt aus Debian Testing, sondern werden unabhängig davon selbst gepflegt. Aus Testing stammt primär der weniger kritische Rest an Bibliotheken und Werkzeugen.
Kernel-Konzept
Auch für das erweiterte Kernel-Konzept gibt es bereits einen Ausblick: Mit linux-tuxedo als Standardkernel und linux-tuxedo-lts als Fallback auf Basis eines Upstream-Longterm-Kernels will TUXEDO eigene Patches bewusst minimal und möglichst upstream-tauglich halten. Details dazu sollen zeitnah in einem eigenen Blogbeitrag ebenso folgen wie Beiträge unter anderem über Btrfs/Snapper und über die weitere Unterstützung für TUXEDO OS auf Ubuntu-Basis.
> Btrfs und Snapper
Als ich ca. 2020 auf Tumbleweed gewechselt bin (nach dem ca. sechsmonatigem Fehltritt mit Standard-Ubuntu), war der snapper und die im Bootmenü angebotenen snapshots (die automatisch vor und nach der Änderung des Paketbestands angelegt werden) einer der wesentlichsten Punkte, die mich direkt angesprochen haben und die ich in Folgen tatsächlich schon benötigt habe. Sei es, weil es tatsächlich schon vorkam, dass ein `dist-upgrade` fehlerhafte bzw. inkompatible Pakete geliefert hat oder der Wechsel von Plasma 5 auf Plasma 6 etwas holprig war. Zurückgerollt, Bug gemeldet, warten, erneut versuchen, klappt.
Falls hier openSUSAAAH-Leute mitlesen … Vielen herzlichen Dank für diese lange Zeit ohne wirkliche “Vollkatastrophen”.
Ich Laufe meiner Zeit mit Linux und dem Ausprobieren anderer Distributionen war ich eigentlich regelmäßig “geschockt”, wie wenig dieses – aus meiner Sicht so sensationelle – Konzept in anderen Distributionen anzufinden war. Sicher, alles hat Gründe, von denen sich mir die meisten, vermutlich aufgrund mangelnder Detailkenntnisse zur Historie einer Distribution oder der verwendeten Dateisysteme, nicht erschließen bzw. erschlossen haben.
Nun ja, lange Rede, gar kein Sinn 🙂 Jetzt freue ich mich darüber, dass diesem Konzept – soweit ich das mitbekommen – aktuell wohl aus verschiedenen Ecken etwas mehr Aufmerksamkeit zuteil wird.
SUSE war eben von Anfang an einer der großen Unterstützer von Btrfs und hat Btrfs als Standard-Dateisystem ausgeliefert. Da bietet sich das dann an. Und ansonsten gibt es noch ein paar alternative Ansätze um ähnliches zu erreichen.
> Alternative Ansätze
Zu meiner Ubuntuzeit wurde mir die “timemachine” (? o. ä.) empfohlen, das habe ich aber eher als klassisches Backup wahrgenommen und nicht so “snapshot-tig” wie ich es dann bei snapper erlebt habe. Würdest Du mir kurz darstellen (gerne auch Links), welche Konzepte das so sind?
Alles was irgendwie in Richtung “immutable” geht, bietet idR ähnliche Fähigkeiten.
Ah! Danke
Liest sich vertrauenserweckend. Hoffentlich können sie das so durchziehen.
Vielleicht gibt es dann doch eine debian-basierte Distribution mit KDE, die man nutzen kann. Debian stable ist es ja leider nicht, weil komplett inkompatibel mit dem Release- bzw Maintainance-Zyklus von KDE.
Ich wünsche Tuxedo Computers viel Erfolg.
Es gibt bereits siduction. Sehr benutztbar und KDE-zentriert 🙂
Und auch mit eingerichtetem Snapper. Habe ich tatsächlich in nun einigen Jahren sid nur einmal (!) gebraucht.
Debian sid ist insbesondere seit dem neuen solver aus apt 3 erstaunlich stabil.
Leider muss man Gnome selbst einspielen. Läuft aber genauso problemlos.
Wir haben halt keinen Betreuer mehr für GNOMe. Falls sich mal einer findet, nehmen wir das gerne wieder auf.
Sid war doch der bleeding edge Zweig, richtig? D.h. täglich >10 zu aktualisierende Pakete. Zumindest soweit meine Erfahrung mit anderen derartigen Distributionen. Und das nervt echt. War der Hauptgrund, warum ich von openSUSE Tumbleweed weg bin.
Bin mittlerweile bei Solus, wo es – abseits Sicherheitsupdates – nur ein mal wöchentlich Updates gibt. Planbar und transparent.
Ich erstelle seit 13 Jahren jeden Tag produktiven Output mit siduction. Man muss sich halt ein wenig drum kümmern, dann ist das völlig handzahm. Zugegeben, vor 20 Jahren war das anders.
Mein erster Gedanke war auch “warum an Testing basteln, wenn es Sid gibt”.
Und mit Siduction sogar ein Projekt, was das seit Jahren (möglicherweise unter dem Radar) erfolgreich praktiziert. Gab/gibt es da keine Kontakte?
Doch, die gibt es. Es geht dabei eher um Akzeptanz bei Kunden und Anwendern. Wie man gesehen hat, kam ja nach der Ankündigung von Testing sofort die Diskussion um die Sicherheit auf. Wäre bei Sid vermutlich noch ausgeprägter. Der Begriff unstable lässt sich halt schwer vermitteln.
Ich halte diese Begrifflichkeiten für sehr missverständlich.
Alle Pakete die zum Zeitpunkt des freeze als stable deklariert werden, kamen so wie sie sind, noch kurz zuvor als unstable in die Debianwelt.
Stable ist nicht stabiler als der Unstable Zweig. Stable enthält auch nicht weniger Fehler als Unstable. Stable verhält sich lediglich statisch in Bezug auf Fehler und Funktion. Es behält die Fehler die es hat und nur später entdeckte Sicherheitslücken werden im Lauf der Zeit bereinigt, während sich “Unstable” in dieser Hinsicht dynamisch verhält.
Man könnte etliche Missverständnisse vermeiden, wenn man die Repositorien in “Dynamic” “Dynamic-Tested” und “Statics” umbenennt.
TUXEDO kann man zum Wechsel auf die Debian-Basis jedenfalls nur gratulieren. Auch ist es dabei kein Fehler sich einiges bei Siduction abzuschauen.
Wenn man jetzt ein System hat, das sich auch vom Laien zurückrollen lässt, dann werden damit auch automatische Paket Upgrades im Hintergrund denkbar, damit dann auch der Bequemlichkeit genüge getan ist.
Immer, wenn Leute mir erzählen wollen, Unstable sei viel zu gefährlich, erkläre ich denen, dass das Unstable sich lediglich auf die Entwickler bezieht 😉
Nein, deine Aussage ist nicht zutreffend. Debian Stable geht durch mehrere Freeze-Phasen in denen releasekritische Bugs systematisch behoben werden. Die überwiegende Zeit hat Stable signifikant weniger releasekritische Bugs als SID und Testing. Man kann sich dies recht schön unter https://bugs.debian.org/release-critical/ ansehen.
Tatsache ist, dass auch die releasekritischen Bugs zuerst in Sid behoben werden, bevor das Paket bzw. der Patch dann nach Stable wandert.
Im Full-Freeze dürfte die Anzahl der releasekritischen Bugs in Sid und Stable exakt gleich sein.
Naturgemäß sind die Zahlen bei Sid während eines Release-Zykus statistisch höher, weil neu hinzukommende Bugs auch dort zuerst beseitigt werden müssen, bevor dann das nächste Stable Release von dieser kontinuierlichen Arbeit profitieren kann.
Du verdrehst die Tatsachen. Zum einen kommen die Zahlen von SID nicht annähernd an die von Stable und dem kommenden Stable während der Releasevorbereitungen heran, was aus meinem Link klar hervorgeht. Zum anderen existiert die Freeze-Phase einzig wegen des kommenden Stable-Release und davon profitiert dann auch SID, und nicht umgekehrt.
Wowie… da bin ich doch fast wieder ein bisschen begeistert.