Debian beharrt auf einem rigiden Stable-Prinzip und hält Versionen exakt auf dem Stand, auf dem sie beim Release waren. Allerdings mit dem Versprechen, sicherheitskritische Probleme durch separate Patches zu beheben. Die Dokumentation der Probleme ist zumindest fragwürdig.
Die Sicherheitsprobleme mit Firefox und X.org bei Debian haben – obwohl inzwischen behoben – mein Interesse geweckt. Das mag sich für manche jetzt alles unfair lesen und vermutlich haben auch andere Distributionen erhebliche Probleme. Ubuntu entledigt sich seiner Sorgen ja einfach mit der Deklaration von universe als nicht supportet. Damit steht der Anwender zwar faktisch auch vor Sicherheitsproblemen, aber formell ist Ubuntu bzw. Canonical auf der sicheren Seite.
Einige Aspekte haben mein Interesse geweckt. Wie immer gehe ich von meinem persönlichen Nutzungsverhalten aus. Das bedeutet der Einsatz von Linux auf dem Desktop mit den für mich wichtigen Programmen. Ein großes Problem möchte ich am Beispiel der Rendering Engines schildern.
In den Release Notes schreibt Debian:
Debian 11 includes several browser engines which are affected by a steady stream of security vulnerabilities. The high rate of vulnerabilities and partial lack of upstream support in the form of long term branches make it very difficult to support these browsers and engines with backported security fixes. Additionally, library interdependencies make it extremely difficult to update to newer upstream releases. Therefore, browsers built upon e.g. the webkit and khtml engines are included in bullseye, but not covered by security support. These browsers should not be used against untrusted websites. The webkit2gtk and wpewebkit engines are covered by security support.
For general web browser use we recommend Firefox or Chromium. They will be kept up-to-date by rebuilding the current ESR releases for stable. The same strategy will be applied for Thunderbird.
Debian Release Notes, abgerufen am 08.01.2022
Das hört sich erst mal nicht so schlimm an. Man nutzt halt keine Browser außer Firefox und Chromium. Wobei Letzteren sollte man angesichts der völlig veralteten Version auch nicht mehr nutzen. Hier sind dann sogar die Release Notes veraltet.
Besonders erstaunlich ist der Verweis auf mangelnden Upstream-Support. Immerhin kümmert sich KDE intensiv um Qt 5.15 und stellt LTS-Support bereit. Warum man diese Updates nicht einfach weiterreichen kann, erschließt sich mir nicht.
Das Problem ist, dass die Rendering Engines noch andere Funktionen haben. Nutze man z. B. das KDE-Mailprogramm KMail bezieht man über die Abhängigkeiten die Pakete libkf5webengineviewer5abi1 und libqt5webenginecore5. Diese benötigt KMail um HTML-Mails korrekt darstellen zu können. Das Problem betrifft auch andere Programme, wie z. B. die Feedreader Akregator oder RSSGuard. Vermutlich ist hier noch mehr betroffen, aber diese beiden Kandidaten kamen mir spontan in den Sinn. Ein Angriff über eine E-Mail ist nun wirklich kein abwegiges Szenario.
Das letzte Update des Pakets libqt5webengine5 gab es im Dezember 2020. Die genutzte Version ist 5.15.2, also nochmal deutlich älter. In Testing liegt eine neuere Version und das Changelog liest sich gar nicht so spektakulär. Das hat mich stutzig gemacht und deshalb habe ich mal bei openSUSE nachgeschaut. Dieses Changelog beschreibt die Änderungen im openSUSE-Paket der Qt5-Webengine. Die Liste der CVEs ist ordentlich.
Gibt man ein paar der CVE-Nummern in den Debian Security Tracker ein, ist immer nur Chromium als betroffenes Paket gelistet. Nur ein Beispiel: CVE-2021-37979. Bei älteren Fehlern ist das Problem angeblich sogar in Debian Stable behoben, was gar nicht sein kann, weil es keine Aktualisierung für die Qt5-Webengine gab. Beispiel: CVE-2021-21128
Es gibt also nur zwei Möglichkeiten. Die openSUSE-Changelogs listen zu viele Probleme oder Debian führt seine Liste der Sicherheitsprobleme nicht vollständig.
Wie dem auch sei: Im Grunde genommen dürfte man kein Programm nutzen, dass auf die Qt Webrendering-Engine zurückgreift bzw. müsste die entsprechende Funktion deaktivieren. Das Problem wird weder in den Release Notes, noch auf irgendwelchen anderen Seiten dargestellt.
Ob das bei den laut Release Notes unterstützten webkit2gtk-Paketen besser ist, habe ich nicht geprüft.
Ich würde mich freuen, wenn jemand das entkräften würde.
Ich würde das Ganze jetzt nicht so überdramatisieren. Es soll sogar immer noch Leute geben, die nutzen sogar heute noch den asbach-uralten Internet Explorer! Linux ist ja per se schon einmal viel sicherer als so manch anderes Betriebssystem. Gleich in Panik oder Hysterie auszubrechen, das scheint mir wieder einmal ein sehr typisch deutsches Phänomen zu sein. Ich bleibe Debian treu und den Chromium nutze ich derzeit allerdings auch nicht, es gibt ja noch diverese andere Browser, die man sich installieren kann (was man auch tun sollte).
Also ich finde es nicht besser, wenn sich z.B. Ubuntu hinter der Regelung, Universe – kein Support von uns, versteckt. Das bringt den Usern eher wenig, zumal die meisten nicht so tief in der Materie sind, um das alles zu überblicken. Wie sollte man das auch, bei der schieren Anzahl von Paketen.
Und gerade hier hat Ubuntu 20.04 ja ein noch älteres Paket an Bord wie Debian, was dann sicher auf alle Distris abfärbt, die darauf aufbauen.
https://packages.ubuntu.com/focal-updates/libqt5webengine5
Da gebe ich dir recht, wirklich gut ist das auch nicht. Ich würde Canonical aber zugute halten, dass die mit Snaps das Problem adressieren möchten (ob man das Konzept mag oder nicht) und nicht einfach so tun als ob es kein Problem gäbe.
Eine richtige Lösung ist meiner Ansicht nach der Schnitt, den Red Hat bei der Transformation Fedora > RHEL macht. Alles was kein Enteprise-Support bekommen soll/kann, fliegt raus. Die Distribution ist dann viel kleiner, aber auf diesen Kern kann ich mich als Anwender dann auch 10 Jahre verlassen.
Ich bin ja an sich auch ein Freund von LTS Distributionen, aber wenn dann solche Pakete über die gesamte Laufzeit trotz bekannter Lücken nicht angefasst werden, ist das für mich schon bedenklich.
Und es ist bestimmt konsequenter dann Dinge rauszuwerfen, die man nicht auf Dauer supporten kann oder will. Das geht auch bestimmt im Enterprisebereich, aber ist das auch für den Normalnutzer dann noch interressant?
Ich benötige nichts spezielles, etwas Bildbearbeitung, einen Multimediaplayer, Mailprogramm, Browser.
Vielleicht sollte ich mal schauen, ob das unter CentOS Stream, oder auch Rocky oder Alma-Linux geht.
Ich glaube das beschreibt ziemlich gut das Dilemma vor dem die Distributoren stehen. Man will den Anwendern möglichst viel bieten, bekommt von Upstream nicht genug LTS-Unterstützung und die verschränkte Paketverwaltung bietet wenig Manövrierraum.
In diesem Dileama befinde ich mich auch. Auf der einen Seite schätze ich Debian seit meinem Umstieg auf meinem Hauptrechner von Windows.
Ein völlig neues Gefühl, einmal konfiguriert und das System läuft klaglos. Doch schon unter Windows war die Sicherheit ein hohes Gut für mich und ich war in Kontakt mit einem Sicherheitsforscher, der mich mit Tipps versorgt hat (Safer und viele weitere Maßnahmen).
Ich verfalle nun nicht in Panik, aber ins Grübeln kommt man dann doch, wenn LTS-stabil u.a. durch Abstriche an der Sicherheit erreicht wird, nicht nur bei Debian.
Die Frage wäre dann nur, was wäre eine adäquater Zwischenweg, weil Rolling Release nichts so meins ist.
Das ist tatsächlich einfach momentan nicht zu lösen.
Ich persönlich habe in den sauren Apfel gebissen und arbeite gegenwärtig mit einem RR-System. Für andere Systeme setze ich weiter auf LTS. Das Schutzbedürfnis ist ja nicht immer gleich und z. B. Ubuntu oder Debian sind bei allen Mängeln trotzdem immer noch ausreichend sichere Systeme.
Ich bin schon länger in der Linuxwelt unterwegs. Angefangen mit Ubuntu über Debian, irgendwann Arch. Bei Ubuntu gefallen mir verschiedene Dinge seitens Canonical nicht, Debian an sich ist sympathisch – aber eher angestaubte Pakete, bei Arch waren immer wieder mal Nacharbeiten notwendig. Ich habe dann ein System gesucht, das nicht RR ist, eine gut konfigurierte Basis installiert und trotzdem nicht mit alter Software umgeht. Ich bin nun seit einer Weile bei Fedora gelandet, das ich vorher nie wirklich ausprobiert habe, und bin total glücklich. Aktuelle Software, schnelle Updates, modernes System, echt gute Doku. LTS ist es dann nicht, da alle 6 Monate eine neue Version erscheint. Das Update von Fedora 34 auf 35 lief aber total unspektakulär ab, einfach der Doku folgen. Ich denke da bleibe ich erstmal. 🙂
Seit einiger Zeit bin ich auch mit Fedora unterwegs und musste feststellen, dass es zumindest „semi-rolling“ ist. Bis auf die grundlegendsten Dinge wie glibc und Compiler rollt innerhalb eines Releases fast alles.
Bei Basis Komponenten wie Kernel, Systemd und Mesa, aber auch bei KDE Frameworks und Plasma, gab es Updates auf neue Versionen.
Ein neues Release unterscheidet sich anscheinend hauptsächlich dadurch, dass es mit dem aktuellsten Compiler neu gebaut wird.