Vorteile von Rolling-Release-Distros bei Sicherheitsupdates?

Die Strategie „stabiler“ Distributionen wie z. B. Debian bezüglich Sicherheitsupdates besteht oft darin, entsprechende Updates in die jeweiligen Pakete zurückzuportieren. Das setzt allerdings voraus, dass der jeweilige Paketbetreuer die Entwicklung verfolgt und Sicherheitsupdates auch als solche gekennzeichnet werden. Des Weiteren ist das Zurückportieren sicherlich nicht immer trivial und ein Maintainer muss wahrscheinlich mehr als nur ein Paket im Auge behalten. Das klingt für mich nach einigen Hürden. Ich denke da z. B. an die Verzögerung beim Aktualisieren von Firefox wegen veralteter Mesa-Pakete vor einer Weile bei Debian.

Was passiert, wenn ein Entwickler mal Update veröffentlicht, dass neben anderen Änderungen ein Sicherheitsupdate enthält, es aber als normales Update kennzeichnet? Ist da ein Rolling-Release-Modell nicht grundsätzlich besser? Wie seht ihr das?

Kommt das vor?

Ich könnte mir vorstellen, dass einige Sicherheitslücken geschlossen werden, ohne dass es an die große Glocke gehängt wird. Außerdem werden Sicherheitslücken nicht immer sofort entdeckt und vielleicht werden manche auch geschlossen, ohne als solche wahrgenommen zu werden – sei es aus Unwissenheit des Entwicklers oder weil es sonst niemand geprüft hat.

Ich schätze aber, das größere Problem ist eher das Zurückportieren und die Anzahl der Pakete die ein einzelner Paktbetreuer überwachen muss.

Im Zweifel kannst du immer noch testing oder sid verwenden. Oder etwas anderes wie Arch/Gentoo um immer auf dem neuesten Stand zu sein. Bedeutet halt potentiell Frickelei und Instabilität aber Updates sind relativ zügig (gilt nicht zwangsläufig für ausgewiesene Sicherheitsupdates).

Meine Frage war, ob Distros mit häufigeren Updates bezüglich Sicherheitsupdates im Vorteil sind und weniger welche Distros man nimmt. :wink:

Ich denke schon. Die diversen nicht-rollenden Distros versuchen ja schon, Sicherheitslücken schnell zu fixen. Ich kann mich aber an einen Fall erinnern, bei dem Google eine Sicherheitslücke im Kernel gemeldet hat, die im Mainline-Kernel auch schnell gefixt wurde - Google selbst hat aber ironischerweise vergessen, diesen Fix in seinen Android-Kernel einzubauen, so dass dieser über längere Zeit vulnerabel war.

Man kann wohl grundsätzlich nicht ganz ausschließen, dass das Einpflegen eines Sicherheitspatches schon mal vergessen werden kann, wenn die Distro nicht den offiziellen LTS-Kernel verwendet (wie das, glaube ich, bei Ubuntu der Fall ist). Und selbst dann kann es in Ausnahmefällen passieren, das ein Patch nicht rückportiert wird, weil sich erst später herausstellt, dass er sicherheitsrelevant ist. Das trifft auch auf Anwendungen zu. Ich will das Problem jetzt nicht höher hängen, als es ist - aber mit dem aktuellen Mainline-Kernel und aktuellen Anwendungspaketen fährt man unter Sicherheitsaspekten schon am besten. Auszuschließen ist freilich nicht, dass es manchmal auch zu Regressionen kommen kann, die allerdings meist schnell korrigiert werden.

Aber auch hier gibt es Unterschiede. Ich habe z.B. die rolling distro OpenSUSE Tumbleweed hier in einer VM laufen und habe schön öfter erlebt, dass etwa ein Firefox-Update (das meist auch Sicherheitsfixes enthält) teils etliche Tage später erst eingespielt wird. Bei Arch Linux dauert das üblicherweise höchstens einen Tag.