Also unwartbar, weil der Aufwand, zu einer Bibliothek in verschiedenen Versionen Sicherheitsupdates bereitzustellen zu hoch wäre?
Hmm, zuerst argumentierst Du, es sei aus Wartbarkeitsgründen Unsinn, unter Debian höher versionierte Software (mitsamt der höher versionierten Abhängigkeiten) zu installieren. Das ist ja gar nicht, was ich will. Ich argumentiere für ein System, was primär darauf ausgelegt ist, mit den neusten Upstream-Versionen zu funktionieren und Sicherheitsupdates upstream anzubringen.
Unwartbar weil du sehr schnell den Überblick verlieren kannst wer welche Version welcher Bibliothek mitbringt und weshalb, so dass du sehr leicht eine übersehen kannst und im System eine Sicherheitslücke verbleibt die du eigentlich glaubtest behoben zu haben.
Den zweiten Teil habe ich bereits beantwortet: Eine Distribution ist ein sehr komplexes System wo die unterschiedlichsten Softwarekomponenten ineinander arbeiten. Änderungen an einer Stelle können unvorhersehbare Probleme an ganz anderen Stellen verursachen. Genau das wird durch das ausschließliche Beheben von Sicherheitslücken verhindert und zeichnet ein stabiles System aus.
Weil aber keine Bugfixreleases einfließen bleiben aber daher bekannte Bugs/Fehlfunktionen in der Software unbehoben. Es werden also nur Sicherheitsaktualisierungen von neuen Upstreamversionen zurückportiert oder downstream angebracht. Wer garantiert, dass die "reinen Sicherheitsaktualisierungen" keine unangenehmen Nebenwirkungen mit sich ziehen?
In Sachen Übersicht: libxyz-1.1 libxyz-2.1.2 ..... Da stehen allenfalls uneinheitliche Versionsschemata im Wege.
Weil aber keine Bugfixreleases einfließen bleiben aber daher bekannte Bugs/Fehlfunktionen in der Software unbehoben.
Weil keine neuen Funktionen einfließen oder existierende umgeschrieben werden kommt kein neuer, wenig getesteter und deshalb fehleranfälligerer Code hinzu.
Es werden also nur Sicherheitsaktualisierungen von neuen Upstreamversionen zurückportiert oder downstream angebracht. Wer garantiert, dass die "reinen Sicherheitsaktualisierungen" keine unangenehmen Nebenwirkungen mit sich ziehen?
Um so weniger Code geändert werden muss desto übersichtlicher und leichter verständlich sind die Änderungen, desto gezielter kann der Code getestet werden und desto unwahrscheinlicher sind Nebenwirkungen.
In Sachen Übersicht: libxyz-1.1 libxyz-2.1.2 ..... Da stehen allenfalls uneinheitliche Versionsschemata im Wege.
Unter Windows ist das ein rechtes Durcheinander. Zuerst musst du einmal wissen wer welche Library überhaupt installiert hat und wo sich diese befindet. Dann musst du wissen ob und wofür sie eingesetzt wird. Dann musst du einen Weg finden diese zuverlässig d.h. dauerhaft upzugraden. Und dann kann es noch immer sein, dass eine kritische Library statisch eingebunden ist.
Auch das von dir angeführte Downgraden ist problematisch, da Sicherheitslücken offen bleiben.
Genauso kann man argumentieren, dass Nicht-Rolling-Release-Distros um die Zeit, die es benötigt, Sicherheitsupdates aus einer neuen Upstreamveröffentlichung zurückzuportieren, länger einer Sicherheitslücke ausgesetzt sind.
Was ist mit Sicherheitsverbesserungen aus einer neuen Upstreamversion, die sich nicht ohne weiteres in eine ältere Version zurückportieren lassen oder solchen, die veränderte Abhängigkeiten bedingen?
Soweit ich mich mit Windows auskenne, ist zumindest die Empfehlung, dass Programme ihre mitgebrachten Bibliotheken in der eigenen Ordnerstruktur unterbringen. Aber dass Windows intrinsisch unsicherer ist, will ich sicher nicht absteiten.
Genauso kann man argumentieren, dass Nicht-Rolling-Release-Distros um die Zeit, die es benötigt, Sicherheitsupdates aus einer neuen Upstreamveröffentlichung zurückzuportieren, länger einer Sicherheitslücke ausgesetzt sind.
Die Argumentation wäre nur unsinnig, denn 1. Werden Sicherheitsupdates üblicherweise koordiniert. 2. Dauert der Backport üblicherweise nicht länger als das Paketieren einer neuen Version. 3. Geht es nicht um Stunden oder Tage bis ein Sicherheitsupdate ausgerollt wird, sondern um das Übersehen und damit vergessen eines Sicherheitsupdates.
Was ist mit Sicherheitsverbesserungen aus einer neuen Upstreamversion, die sich nicht ohne weiteres in eine ältere Version zurückportieren lassen oder solchen, die veränderte Abhängigkeiten bedingen?
Sicherheitsupdates beinhalten üblicherweise nur minimale Codeänderungen welche sich sehr einfach portieren lassen und auch keine neuen Abhängigkeiten erfordern.
Soweit ich mich mit Windows auskenne, ist zumindest die Empfehlung, dass Programme ihre mitgebrachten Bibliotheken in der eigenen Ordnerstruktur unterbringen. Aber dass Windows intrinsisch unsicherer ist, will ich sicher nicht absteiten.
Damit hast du auch noch die selbe Version der Library mehrfach auf dem System, also der Worst Case.
"üblicherweise koordiniert" Längst nicht jeder Entwickler schert sich darum, dass seine Software möglichst gut von bestimmten Distributoren wartbar ist. Dazu kennen sich die Sicherheitsbetreuer in der jeweiligen Codebasis verglichen mit den Entwicklern nur marginal aus.
"üblicherweise nur minimale Codeänderungen" Wenn das doch immer so einfach wäre und Sicherheitslücken sich immer bloß auf wenige unabhängige Codezeilen beschränkten.
Bezüglich des Worst Case: Was meinst Du warum sich auf dem Bereich Virtualisierung/ Sandboxing/Anwendungsisolation usw. so viel tut?
"üblicherweise koordiniert" Längst nicht jeder Entwickler schert sich darum, dass seine Software möglichst gut von bestimmten Distributoren wartbar ist.
Das ist bei Open Source auch nicht erforderlich, da jeder das Problem beheben kann und nicht nur ein bestimmter Entwickler.
Dein Argument ist zudem nicht valide, du du willkürliche Annahmen triffst. Du nimmst beispielsweise an, dass der Entwickler überhaupt und zeitnah eine neue Version veröffentlicht. Das ist keineswegs gesagt.
Dazu kennen sich die Sicherheitsbetreuer in der jeweiligen Codebasis verglichen mit den Entwicklern nur marginal aus.
Auch hier triffst du wieder willkürliche Annahmen. Du nimmst stillschweigend an, dass Upstream-Entwickler autonmatisch ein besseres Sicherheitsverständnis haben als ein Sicherheitsbetreuer welcher auf diese Aufgabe spezialisiert ist. Dabei ist eher gegenteiliges anzunehmen, D-Link führt das gerade eindrucksvoll vor.
"üblicherweise nur minimale Codeänderungen" Wenn das doch immer so einfach wäre und Sicherheitslücken sich immer bloß auf wenige unabhängige Codezeilen beschränkten.
Das ist auch die Regel.
Bezüglich des Worst Case: Was meinst Du warum sich auf dem Bereich Virtualisierung/ Sandboxing/Anwendungsisolation usw. so viel tut?
Themaverfehlung. Damit werden keine Sicherheitslücken behoben sondern deren Auswirkungen minimiert.
Genau. Dadurch dass Debian zur Wahrung der Universalität Pakete in der Distribution hat, die seit Jahren nicht mehr entwickelt werden (und deren Benutzerkreis möglicherweise teilweise überschaubar ist) holt man sich zunächst mehr Arbeit ins Haus.
Aber du willst mir ja wohl nicht erzählen, dass das Debian-Sicherheitsteam gründliche Audits für sämtliche Pakete vornimmt. Von der schieren Anzahl abgesehen, geht es hier um zig verschiedene Sprachen, zig verschiedene Formatierungskonventionen, mitunter kaum dokumentierten Code.
Ich habe doch gerade geschrieben, dass die Upstreamentwickler sich nicht zwangsläufig vorrangig um die Sicherheit scheren (und auch nicht können oder müssen). Ich plädiere nur dazu, die Sicherheitsupdates auf Basis der Upstreamversion zu verwenden.
Dein D-Link-Beispiel greift nicht. Es handelt es sich hier um proprietäre Software (und falls du contrib und non-free verwendest, führst Du deine Argumentation ad absurdum).
Der Unterschied zwischen dem Beheben der Sicherheitslücken oder der Minimierung der möglichen Auswirkungen auf andere Weise ist doch nur technischer Natur.
Genau. Dadurch dass Debian zur Wahrung der Universalität Pakete in der Distribution hat, die seit Jahren nicht mehr entwickelt werden (und deren Benutzerkreis möglicherweise teilweise überschaubar ist) holt man sich zunächst mehr Arbeit ins Haus.
Debian-Entwickler sind Freiwillige, üblicherweise setzen sie die Pakete selbst ein, die sie betreuen. Von Mehrarbeit kann deshalb keine Rede sein.
Aber du willst mir ja wohl nicht erzählen, dass das Debian-Sicherheitsteam gründliche Audits für sämtliche Pakete vornimmt. Von der schieren Anzahl abgesehen, geht es hier um zig verschiedene Sprachen, zig verschiedene Formatierungskonventionen, mitunter kaum dokumentierten Code.
Schon wieder eine Themaverfehlung. Es geht nicht um die Suche nach Sicherheitslücken sondern um die Behebung derselbigen. Das sind zwei völlig unterschiedliche Aufgaben.
Ich habe doch gerade geschrieben, dass die Upstreamentwickler sich nicht zwangsläufig vorrangig um die Sicherheit scheren (und auch nicht können oder müssen). Ich plädiere nur dazu, die Sicherheitsupdates auf Basis der Upstreamversion zu verwenden.
Ich habe bereits erklärt warum dies auf einem stabilen System nicht möglich ist, wenn Upstream keine reinen Sicherheitsupdates bereithält.
Dein D-Link-Beispiel greift nicht. Es handelt es sich hier um proprietäre Software (und falls du contrib und non-free verwendest, führst Du deine Argumentation ad absurdum).
Das Beispiel soll zeigen, dass die Entwickler einer Software nicht unbedingt der bestmögliche Ansprechpartner zur Behebung von Sicherheitslücken sind. Das ist nicht von der Art der Software abhängig.
Der Unterschied zwischen dem Beheben der Sicherheitslücken oder der Minimierung der möglichen Auswirkungen auf andere Weise ist doch nur technischer Natur.
Es wird sehr gefährlich wenn jemand, so wie du, Sandboxing in eine Diskussion einbringt, bei der es um die Behebung von Sicherheitslücken geht. Es kann nämlich sehr schnell der Eindruck entstehen, dass durch die Abschottung von Prozessen das tatsächliche Beheben der Sicherheitslücken plötzlich nicht mehr so wichtig ist. Das wäre so, als wenn nach dem Anlegen des Sicherheitsgurtes im Auto eine sichere Fahrweise nicht mehr so wichtig wäre. Eine zusätzlich Sicherheitsbarriere ist hingegen gerade nicht dazu da, um deshalb an anderer Stelle zu schludern.
Nur zum letzten Beispiel, ansonsten verteidigst Du dich dauernd gegen Standpunkte, die nicht die meinen sind. (So liegt es mir ja gar nicht an einem stabilen System in deinem Sinne. Ich brauche keine bessere Stabilität als die, die ich momentan mit Rolling Release ungetrübt erlebe.)
Gäbe es zum Beispiel Autos, die auf kreuzungsfreien Schienen entlanggezogen würden, gäbe es gar keine unsicheren Autos. Oder man packe um die Autos jeweils 30m Schaumstoffmasse - auch Sanboxing kann ja durchaus mit einem Overhead bezüglich Ressourcenverbrauch verbunden sein
Du hast mir dauernd die Debian-Philosophie erklärt, deren Motivation ich ja nachvollziehe aber für mich persönlich nicht für richtig und nötig halte.
Die 30m Schaumstoff waren offensichtlich eine völlig willkürliche Verbildlichung.
Aber Schaumstoff ist nicht gleich Schaumstoff und je nach Elastizitäts- und Schermodul sowie weiteren mechanischen Eigenschaften dürfte da sogar weit weniger Material reichen. Aber bevor ich den Crashtest machte würde ich das lieber modellieren. Am besten mit aktueller Freier Software.
Ja entschuldige, ich habe dir die Beweggründe hinter Debian erklärt nachdem deine Argumentation zeigte, dass sie dir nicht bekannt sein können. Die Relevanz für dich persönlich wirst auch du erst feststellen können, nachdem sie dir bekannt sind und nicht bereits vorher.
Und was genau verstehst Du unter "Wartbarkeit"?
Sicherheitsupdates zählen üblicherweise zur Systemwartung.
Also unwartbar, weil der Aufwand, zu einer Bibliothek in verschiedenen Versionen Sicherheitsupdates bereitzustellen zu hoch wäre?
Hmm, zuerst argumentierst Du, es sei aus Wartbarkeitsgründen Unsinn, unter Debian höher versionierte Software (mitsamt der höher versionierten Abhängigkeiten) zu installieren.
Das ist ja gar nicht, was ich will.
Ich argumentiere für ein System, was primär darauf ausgelegt ist, mit den neusten Upstream-Versionen zu funktionieren und Sicherheitsupdates upstream anzubringen.
Unwartbar weil du sehr schnell den Überblick verlieren kannst wer welche Version welcher Bibliothek mitbringt und weshalb, so dass du sehr leicht eine übersehen kannst und im System eine Sicherheitslücke verbleibt die du eigentlich glaubtest behoben zu haben.
Den zweiten Teil habe ich bereits beantwortet: Eine Distribution ist ein sehr komplexes System wo die unterschiedlichsten Softwarekomponenten ineinander arbeiten. Änderungen an einer Stelle können unvorhersehbare Probleme an ganz anderen Stellen verursachen. Genau das wird durch das ausschließliche Beheben von Sicherheitslücken verhindert und zeichnet ein stabiles System aus.
Weil aber keine Bugfixreleases einfließen bleiben aber daher bekannte Bugs/Fehlfunktionen in der Software unbehoben.
Es werden also nur Sicherheitsaktualisierungen von neuen Upstreamversionen zurückportiert oder downstream angebracht.
Wer garantiert, dass die "reinen Sicherheitsaktualisierungen" keine unangenehmen Nebenwirkungen mit sich ziehen?
In Sachen Übersicht:
libxyz-1.1
libxyz-2.1.2
.....
Da stehen allenfalls uneinheitliche Versionsschemata im Wege.
Weil keine neuen Funktionen einfließen oder existierende umgeschrieben werden kommt kein neuer, wenig getesteter und deshalb fehleranfälligerer Code hinzu.
Um so weniger Code geändert werden muss desto übersichtlicher und leichter verständlich sind die Änderungen, desto gezielter kann der Code getestet werden und desto unwahrscheinlicher sind Nebenwirkungen.
Unter Windows ist das ein rechtes Durcheinander. Zuerst musst du einmal wissen wer welche Library überhaupt installiert hat und wo sich diese befindet. Dann musst du wissen ob und wofür sie eingesetzt wird. Dann musst du einen Weg finden diese zuverlässig d.h. dauerhaft upzugraden. Und dann kann es noch immer sein, dass eine kritische Library statisch eingebunden ist.
Auch das von dir angeführte Downgraden ist problematisch, da Sicherheitslücken offen bleiben.
Genauso kann man argumentieren, dass Nicht-Rolling-Release-Distros um die Zeit, die es benötigt, Sicherheitsupdates aus einer neuen Upstreamveröffentlichung zurückzuportieren, länger einer Sicherheitslücke ausgesetzt sind.
Was ist mit Sicherheitsverbesserungen aus einer neuen Upstreamversion, die sich nicht ohne weiteres in eine ältere Version zurückportieren lassen oder solchen, die veränderte Abhängigkeiten bedingen?
Soweit ich mich mit Windows auskenne, ist zumindest die Empfehlung, dass Programme ihre mitgebrachten Bibliotheken in der eigenen Ordnerstruktur unterbringen.
Aber dass Windows intrinsisch unsicherer ist, will ich sicher nicht absteiten.
Die Argumentation wäre nur unsinnig, denn
1. Werden Sicherheitsupdates üblicherweise koordiniert.
2. Dauert der Backport üblicherweise nicht länger als das Paketieren einer neuen Version.
3. Geht es nicht um Stunden oder Tage bis ein Sicherheitsupdate ausgerollt wird, sondern um das Übersehen und damit vergessen eines Sicherheitsupdates.
Sicherheitsupdates beinhalten üblicherweise nur minimale Codeänderungen welche sich sehr einfach portieren lassen und auch keine neuen Abhängigkeiten erfordern.
Damit hast du auch noch die selbe Version der Library mehrfach auf dem System, also der Worst Case.
"üblicherweise koordiniert"
Längst nicht jeder Entwickler schert sich darum, dass seine Software möglichst gut von bestimmten Distributoren wartbar ist.
Dazu kennen sich die Sicherheitsbetreuer in der jeweiligen Codebasis verglichen mit den Entwicklern nur marginal aus.
"üblicherweise nur minimale Codeänderungen"
Wenn das doch immer so einfach wäre und Sicherheitslücken sich immer bloß auf wenige unabhängige Codezeilen beschränkten.
Bezüglich des Worst Case:
Was meinst Du warum sich auf dem Bereich Virtualisierung/ Sandboxing/Anwendungsisolation usw. so viel tut?
Das ist bei Open Source auch nicht erforderlich, da jeder das Problem beheben kann und nicht nur ein bestimmter Entwickler.
Dein Argument ist zudem nicht valide, du du willkürliche Annahmen triffst. Du nimmst beispielsweise an, dass der Entwickler überhaupt und zeitnah eine neue Version veröffentlicht. Das ist keineswegs gesagt.
Auch hier triffst du wieder willkürliche Annahmen. Du nimmst stillschweigend an, dass Upstream-Entwickler autonmatisch ein besseres Sicherheitsverständnis haben als ein Sicherheitsbetreuer welcher auf diese Aufgabe spezialisiert ist. Dabei ist eher gegenteiliges anzunehmen, D-Link führt das gerade eindrucksvoll vor.
Das ist auch die Regel.
Themaverfehlung. Damit werden keine Sicherheitslücken behoben sondern deren Auswirkungen minimiert.
Genau. Dadurch dass Debian zur Wahrung der Universalität Pakete in der Distribution hat, die seit Jahren nicht mehr entwickelt werden (und deren Benutzerkreis möglicherweise teilweise überschaubar ist) holt man sich zunächst mehr Arbeit ins Haus.
Aber du willst mir ja wohl nicht erzählen, dass das Debian-Sicherheitsteam gründliche Audits für sämtliche Pakete vornimmt. Von der schieren Anzahl abgesehen, geht es hier um zig verschiedene Sprachen, zig verschiedene Formatierungskonventionen, mitunter kaum dokumentierten Code.
Ich habe doch gerade geschrieben, dass die Upstreamentwickler sich nicht zwangsläufig vorrangig um die Sicherheit scheren (und auch nicht können oder müssen). Ich plädiere nur dazu, die Sicherheitsupdates auf Basis der Upstreamversion zu verwenden.
Dein D-Link-Beispiel greift nicht. Es handelt es sich hier um proprietäre Software (und falls du contrib und non-free verwendest, führst Du deine Argumentation ad absurdum).
Der Unterschied zwischen dem Beheben der Sicherheitslücken oder der Minimierung der möglichen Auswirkungen auf andere Weise ist doch nur technischer Natur.
Debian-Entwickler sind Freiwillige, üblicherweise setzen sie die Pakete selbst ein, die sie betreuen. Von Mehrarbeit kann deshalb keine Rede sein.
Schon wieder eine Themaverfehlung. Es geht nicht um die Suche nach Sicherheitslücken sondern um die Behebung derselbigen. Das sind zwei völlig unterschiedliche Aufgaben.
Ich habe bereits erklärt warum dies auf einem stabilen System nicht möglich ist, wenn Upstream keine reinen Sicherheitsupdates bereithält.
Das Beispiel soll zeigen, dass die Entwickler einer Software nicht unbedingt der bestmögliche Ansprechpartner zur Behebung von Sicherheitslücken sind. Das ist nicht von der Art der Software abhängig.
Es wird sehr gefährlich wenn jemand, so wie du, Sandboxing in eine Diskussion einbringt, bei der es um die Behebung von Sicherheitslücken geht. Es kann nämlich sehr schnell der Eindruck entstehen, dass durch die Abschottung von Prozessen das tatsächliche Beheben der Sicherheitslücken plötzlich nicht mehr so wichtig ist. Das wäre so, als wenn nach dem Anlegen des Sicherheitsgurtes im Auto eine sichere Fahrweise nicht mehr so wichtig wäre. Eine zusätzlich Sicherheitsbarriere ist hingegen gerade nicht dazu da, um deshalb an anderer Stelle zu schludern.
Nur zum letzten Beispiel, ansonsten verteidigst Du dich dauernd gegen Standpunkte, die nicht die meinen sind.
(So liegt es mir ja gar nicht an einem stabilen System in deinem Sinne. Ich brauche keine bessere Stabilität als die, die ich momentan mit Rolling Release ungetrübt erlebe.)
Gäbe es zum Beispiel Autos, die auf kreuzungsfreien Schienen entlanggezogen würden, gäbe es gar keine unsicheren Autos.
Oder man packe um die Autos jeweils 30m Schaumstoffmasse - auch Sanboxing kann ja durchaus mit einem Overhead bezüglich Ressourcenverbrauch verbunden sein
Ich verteidige nichts sondern erkläre dir die Zusammenhänge, da deine Argumentation darlegt, dass sie dir nicht bekannt sein können.
Wenn du übrigens glaubst ein Auto mit 30m Schaumstoffmasse sicher machen zu können, dann sollten du damit einen Crashtest machen - oder besser nicht.
Du hast mir dauernd die Debian-Philosophie erklärt, deren Motivation ich ja nachvollziehe aber für mich persönlich nicht für richtig und nötig halte.
Die 30m Schaumstoff waren offensichtlich eine völlig willkürliche Verbildlichung.
Aber Schaumstoff ist nicht gleich Schaumstoff und je nach Elastizitäts- und Schermodul sowie weiteren mechanischen Eigenschaften dürfte da sogar weit weniger Material reichen. Aber bevor ich den Crashtest machte würde ich das lieber modellieren.
Am besten mit aktueller Freier Software.
Ja entschuldige, ich habe dir die Beweggründe hinter Debian erklärt nachdem deine Argumentation zeigte, dass sie dir nicht bekannt sein können. Die Relevanz für dich persönlich wirst auch du erst feststellen können, nachdem sie dir bekannt sind und nicht bereits vorher.