Und wieder einmal ein neues Release wo nicht alle Pakete durch den Security Support abgedeckt sind, beispielsweise webkit oder gtk ... Schade Debian, ich hatte gehofft dass sich endlich mal etwasändert, aber so werde ich wohl doch lieber zu BSD gehen ...
Die nicht supporteten oder supportbaren Khtml- und Webkit-Engines (Chromium ist in Debian ja davon nicht betroffen, wohl aber u.a. Epiphany-Browser (i.e. das "Web"-Etwas von Gnome3), Midori, Qupzilla und Konqueror) müssten halt allesamt aus Debian Stable entfernt werden. Nur traut sich das Debian offenbar nicht, weil das bedeuten würde, dass man wichtige Teile von KDE Plasma und Gnome3 nicht mehr ausliefern könnte. U.U. würden dann z.B. auch Gimp oder Evolution fehlen.
Man sieht, dass der Umstieg vieler freier Softwareprojekte auf die Webkit-Engine vor einigen Jahren und die damalige Abkehr von der Gecko-Engine (weil diese ja schon damals offenbar zu oft aktualisiert wurde, weshalb man immer wieder seine eigenen Anwendungen anpassen musste) in sicherheitstechnischer Hinsicht eine einzige Katastrophe erzeugt hat: Die meisten Linux-Distros sind nun allesamt mit unsicheren Browser-Engines vollgepackt.
Es gibt Hoffnung. Fedora und einige Rolling Release-Distros sind davon nicht betroffen.
Zudem ist man ja lernfähig.
Siehe z.B. hier: https://bugzilla.redhat.com/show_bug.cgi?id=1375809
Hatte Debian in Wheezy noch die Webkitgtk-Abhängigkeit zu Webkit 1.0.0 (!) als Strict Dependency enthalten, hat sich das mittlerweile geändert. Hoffentlich kommt ab Gimp 3.x niemand mehr auf die Idee, die ganze unselige Geschichte mit einer etwas moderneren Webkitgtk-Engine zu wiederholen, die würde mit der Zeit genauso u.a. in Debian vor sich hinverrotten.
Wer nun aber anfangen möchte, über Debian herzuziehen, der sollte seine gerade benutzte Distro einmal auf derartige Abhängigkeiten abklopfen. Einfach in der Paketverwaltung nach Webkit suchen und dann einmal versuchen, diese Engines zu deinstallieren (falls kein Sicherheitssupport für diese bestehen sollte). Aber bitte erst schauen, was dann sonst noch so deinstalliert würde.
Debian hat dieses Problem schon verstanden, nur deshalb weist man so vehement auf Firefox und Chromium als sichere Webbrowser in Debian hin.
ich sehe sowas eher als fundamentales gnu/linux sicherheits-problem in den meisten distros. es wird immer von hoher sicherheit gesprochen, wenn man jedoch tiefer ins system schaut wird es schnell gruselig.
gleiche frage gilt wenn Firefox ESR zb nicht mehr offiziell weiter gepatcht wird. Ich habe schlichtweg kein gutes Gefühl wenn dann die Distros selbst anfangen sicherheitsupdates manuell nachzufriemeln. M.E. gehöhrt dann eher die nächste ESR-Version Distroseitig angeboten.
Und was machst Du bei Paketen die keine ESR oder Security Fixes anbieten?
Die Aussage man nehme bitte die nächste neue (größere) Version funktioniert leider nur sehr selten. Neue Versionen bringen in der Regel auch neue Abhängigkeiten mit sich deren Auswirkungen durch das Securityteam nicht prüfbar sind. Aber einen oder mehrere Diff(s) für einen Security Fix einspielen der sich relativ leicht aus den Upstream Commits holen lässt ist das deutlich kleinere Übel. Für neuere Versionen gibt es Backports, hier ist aber auch der Admin verantwortlich dafür, dass es auch dem Updaten wieder rund läuft.
Ich kann jeden der sich über die Problematik mit Security Fixen im Bezug zu Debian beschwert ganz herzlich dazu einladen mal an einem Sprint teilzunehmen und zu versuchen seine Meinung dort zu vertreten. Man wird schnell merken das es kein schwarz/weiß gibt sondern ein vielschichtiges Bunt mit einer klaren konservativen Linie. Im Mittelpunkt steht der Benutzer und die Stabilität.
Der Browser ist jedoch m.E. im Desktop-Betrieb mit die für Angriffe empfindlichste Komponente. Ich frage mich wie man hier ernsthaft von neueren ESR-Versionen SecurityBugs auf alte ESR-Versionen sinnvoll Backporten will ohne ggf. neue Security-Probleme zu öffnen.
Ich fänd es gut wenns für Debian eine einfache Möglichkeit gäb wenn Firefox+Thunderbird in zwei Versionen Verfügbar wäre. Einmal in der Stablen Version wie bisher, und einmal als "mozilla-firefox-new" Package, welches immer ein offiziell supportetes ESR-Package beinhaltet. Ich weis das das insbesondere bei internen+externen Libs und Plugins etc. ggf regressionen nach sich ziehen würde.
Hier geht es um die Desktop-Sicherheit. Wir wissen inzwischen alle das Geheimdienste und Co die Sicherheit massiv zu unterminieren versuchen - daher sollten solche eventuellen Bugs/Probleme nicht mehr unter den Teppich gekehrt werden.
>> Für neuere Versionen gibt es Backports Meine Erfahrung mit Debian vor einigen Jahren: Backport für Firefox bzw IceWeasel aktiviert. Firefox/Iceweasel wurden aktualisiert. Thunderbird nicht - Der Debian-Howto gefolgt - es musste ein anderer Backport-Server aktiviert werden - es wurden andere im system inkompatible libs ausgetauscht - bullshitt-bingo-scheisse - wir reden hier von einem "Desktop" - da möchte ich mir frickelkram ersparen. Und wer garantiert mir dann das die Backports regelmaessig gewartet werden? - wohl niemand mehr.
Dann fahr ich bald besser Firefox/Thunderbird der Distro runterzuwerfen und mir in /home/foobar/bin/ eigene aktuelle Binarys abzulegen Übrigens - unter Ubuntu14.04 oderso gabs in diesem Fall (manuell installierter Firefox) reproduzierbare adobe-flash-crashes - wenn man das flash-video auf vollbild gestellt hat, sonst nicht - Frickelei hoch 3!
Firefox und Thunderbird gibt es nicht im Backports Repository sondern "nur" über die Securityupdates. Dies ist eine Besonderheit da beide Pakete im eigentlichen Sinne neue Versionen sind und somit eigentlich nicht in den Security Zweig gehören.
Du hast scheinbar ein anderes Verständnis von Mozilla ESR Versionen wie mir scheint. Es gibt da nicht mehrere Versionen, es gibt immer nur eine und diese Version ist die von Mozilla unterstützte Version. Insofern benutzt Du diese oder lässt es. Diese wird übrigens alle 6 Wochen sehr regelmäßig veröffentlicht.
Welche zwei Versionen soll es denn geben? Es gibt beim Firefox die ESR Versionen die faktisch nur Security und Regression Updates, beim Thunderbird gibt es in Anlehnung der Firefox ESR Version einen ähnlichen Releasezyklus. Und zusätzlich gibt es noch die normalen Entwicklungsreleases. Vom Securityteam werden aber nur die ESR Version vom Firefox bzw. an dessen Anlehnung die Thunderbirdversion eingepflegt. Für mehr Sachen sind auch keine Ressourcen da. Wer trotzdem Bleeding Etch benutzen will kann gerne auf Versionen von Upstream zurück greifen. Wer bei der Pflege der Pakete (und nicht "nur" einen Fix) helfen will ist gerne eingeladen mitzuwirken. In den letzten fünf Jahren ist dies aber nicht einmal in vorgekommen.
Und noch etwas was Du vermutlich nicht gerne hören wirst, Backports gehört genauso wie contrtib oder non-free nicht zum offiziellen Debian, das es das doch gibt ist eine freiwillige Zusatzleistung der Maintainer. Man kommt nicht umhin sich mal mit dem Wesen und der Philosophie von Debian zu beschäftigen bevor man Kritik üben will.
beschäftige Dich einfach mit den Release Zyklen von Firefox ESR und Du wirst feststellen das in 1-2 Jahren neuere Firefox ESR versionen von Mozilla betrieben werden als die jetzt in Debian 9 mitgelieferte. Die Frage ist ob dann noch die dann veraltete Firefox ESR version sinnvoll gepatcht werden kann, oder ob es nicht sinnvoller wäre ein neues Package für die dann aktuelle Firefox-ESR version anzubieten. m.e wäre dann aus sicherheitssicht ein upgrade auf firefox esr 58.x sinnvoller - und zwar offiziell und nicht via 'freiwilligem' backport gefrickel.
---------
Schön das du die aus Sicherheitssicht fragwürdigen Backport-Qualität hier bestätigst.
---------
Das Ubuntu != Debian ist mir nichts neues - das Beispiel zeigt mir dennoch das Linux nach wie vor frickelig im Desktopbdtrieb sein kann.
Ich wollte gerade Midori 0.5.11 in Debian Stretch nachinstallieren. Synaptic blendet mir dann als zu installierende Abhängigkeit u.a. libwebkitgtk-1.0.0 ein.
Was soll man dazu noch sagen? Ein Midori-Browser wie derjenige in Debian, der libwebkitgtk-1.0.0 zum Webbrowsen benötigt, muss aus Sicherheitsgründen komplett aus dem Main-Repo entfernt werden, zusammen mit libwebkitgtk-1.0.0.
Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.
Eine derartige Liste gibt es nicht da das Security keine Ausnahmen macht was Softwarepakete angeht. Wenn CVEs bekannt werden dann ordnet das Security Team dies den Paketen zu und bittet zunächst die Paketmaintainer die CVEs zu fixen. Sollte des Paket aber keinen Maintainer besitzen dann springen gerne auch mal andere Maintainer ein und erst ganz zuletzt werden manchen Pakete durch das Security mit Fixes versorgt.
Gibt es für ein Paket keine Fixes und die Sicherheitsprobleme sind gravierend wird das Paket aus der Distribution entfernt.
Die gibt es. Du musst das Paket debian-security-support nachinstallieren und danach check-support-status in einem Konsolenfenster ausführen. Etwaige installierte und nicht betreute Pakete werden dann angezeigt.
Ich erhalte unter Debian Stretch folgende Ausgabe: joeuser:~$ check-support-status Eingeschränkte Versorgung mit Sicherheitsaktualisierungen für eines oder mehrere Pakete
Leider war es nötig, die Versorgung mit Sicherheitsaktualisierungen für einige Pakete einzuschränken.
Davon sind die folgenden auf diesem System gefundenen Pakete betroffen:
* Quelle:qtwebkit-opensource-src Einzelheiten: No security support upstream and backports not feasible, only for use on trusted content Betroffenes Binärpaket: - libqt5webkit5:amd64 (installierte Version: 5.7.1+dfsg-1)
Nun ja, dies heißt aber immer noch nicht das es keine Fixes geben wird. Der Hinweis weißt darauf hin das es von Upstream keinen Support für dieses Paket gibt. Andere Distributionen haben dieses Problem auch und Fixes machen dann gerne mal die Runde.
Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.
Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Übersetzt: „Und wieder hat mal jemand ne Web Engine gemacht, die sich nur sehr schwer auf stabilen Distri updaten lässt, weil kompliziert mit GTK vernetzt. Die Schuld gebe ich aber Debian, nicht WebkitGTK/Qt. Ach, wie schade.“
Derjenige, der die Distribution anbietet, steht primär in der Verantwortung. Mein Posting bezog sich nicht nur auf Debian.
Was hindert Debian, Ubuntu, OpenSuse oder Mint daran, Konqueror, Qupzilla, Epiphany-Browser oder Midori beim Bekanntwerden von remote ausnutzbaren Sicherheitslücken aus einer Debian-Distro mit dem nächsten Point-Release herauszunehmen, wenn man diese Lücken nicht patchen kann oder der Aufwand dafür zu groß ist?
Bei Owncloud in Ubuntu war es ja auch möglich, mit Rekonq verfuhr Debian aus anderen Gründen geradezu knallhart.
Ein remote ausnutzbares Sicherheitsloch? Keiner kann oder will patchen? Mein lieber Maintainer, dort ist die Tür für Dein Paket. Raus damit!
Der Text stimmt natürlich so nicht, ich habe mich oben an einem Punkt verschrieben.
Natürlich ist jede Distro für sich selbst verantwortlich ist und Webbrowser mit Sicherheitslücken, die remote ausnutzbar sind, sollten am Besten aus einer Distribution herausgenommen werden.
Debian ist davon nicht alleine betroffen.
OpenSuse z.B. hat gerade Seamonkey mit im Angebot, obgleich Seamonkey mehrere Versionen hinter einer sicheren Firefox- oder Firefox-ESR-Version hinterherhinkt. Mit Epiphanybrowser hat OpenSuse genau das gleiche Problem wie Debian.
Die Beispielliste über die meisten Distros hinweg ist hier riesengroß und keinesfalls auf Debian beschränkt.
Das umrissene Problem ist real. Mit "Mir doch egal, ob überhaupt gepatcht wird." kommt man da nicht weiter.
Ich habe nicht gesagt, dass es mir egal ist. Aber wenn jemand eine Web Engine baut, die den halben GTK Stack neu haben will bei einer neuen Version, wie soll Debian das dann patchen? Aber du hast Recht, sie hätten das Ding einfach entfernen sollen. Nur dann ist das Problem, dass z.B. viele einfache Programme nicht mehr gehen, weil sie Webkit fürs Rendern benutzen.
"Nur dann ist das Problem, dass z.B. viele einfache Programme nicht mehr gehen, weil sie Webkit fürs Rendern benutzen."
Genau das ist das Hauptproblem. Man ruft ein Programm auf und weiß gar nicht, dass eine solche unsichere Webkit-Engine mitbenutzt wird.
Die Distribution müsste dann KDE- oder GTK-/Gnome-Programme so kompilieren, dass diese Webkit- oder Khtml-Engines nur lokale Inhalte anzeigen. Gnomes Epiphany-Browser z.B. dürfte IMO unter Debian gar nicht ins Internet gelangen, zumal sich hier noch nicht einmal mehr Javascript in der GUI abschalten lässt.
Und da fängt dann eine mögliche Bevormundung des Nutzers an, die Debian eher ablehnt. Was bleibt, ist dem Nutzer zu sagen, dass er unter Debian machen kann, was er will, auch mit unsicherer Software im Internet herumsurfen, wenn er das so möchte, nur hat es Debian vorher immerhin deutlich gesagt, dass das in punkto Sicherheit ganz großer Mist ist.
Das ist etwa so, als würde man mit dem alten Internet Explorer oder einem alten T-Online-Browser auf einem noch "unterstützten" Windows im Internet herumsurfen.
Keine Distribution bekommt es momentan hin, die Webkit- und Khtml-Engines etwas älterer KDE- und Gnome-Desktops so anzubieten, dass man mit diesen sicher im Internet surfen kann. Die einzige Ausnahme sind regelmäßig aktualisierte Distributionen wie Fedora oder Rolling-Release-Distros.
Nur: Man weiß, dass Webkit-Upstream ältere Webkitversionen nicht mehr supportet. Wieso ruft man dann für das Anzeigen von Internetinhalten unter Debian nicht einfach erst einmal standardmäßig Firefox oder Chromium auf (was natürlich als Option überschreibbar bzw. veränderbar bliebe)?
Und wieder einmal ein neues Release wo nicht alle Pakete durch den Security Support abgedeckt sind, beispielsweise webkit oder gtk ...
Schade Debian, ich hatte gehofft dass sich endlich mal etwasändert, aber so werde ich wohl doch lieber zu BSD gehen ...
Die nicht supporteten oder supportbaren Khtml- und Webkit-Engines (Chromium ist in Debian ja davon nicht betroffen, wohl aber u.a. Epiphany-Browser (i.e. das "Web"-Etwas von Gnome3), Midori, Qupzilla und Konqueror) müssten halt allesamt aus Debian Stable entfernt werden. Nur traut sich das Debian offenbar nicht, weil das bedeuten würde, dass man wichtige Teile von KDE Plasma und Gnome3 nicht mehr ausliefern könnte. U.U. würden dann z.B. auch Gimp oder Evolution fehlen.
Man sieht, dass der Umstieg vieler freier Softwareprojekte auf die Webkit-Engine vor einigen Jahren und die damalige Abkehr von der Gecko-Engine (weil diese ja schon damals offenbar zu oft aktualisiert wurde, weshalb man immer wieder seine eigenen Anwendungen anpassen musste) in sicherheitstechnischer Hinsicht eine einzige Katastrophe erzeugt hat: Die meisten Linux-Distros sind nun allesamt mit unsicheren Browser-Engines vollgepackt.
...unglaublich...
Es gibt Hoffnung. Fedora und einige Rolling Release-Distros sind davon nicht betroffen.
Zudem ist man ja lernfähig.
Siehe z.B. hier:
https://bugzilla.redhat.com/show_bug.cgi?id=1375809
Hatte Debian in Wheezy noch die Webkitgtk-Abhängigkeit zu Webkit 1.0.0 (!) als Strict Dependency enthalten, hat sich das mittlerweile geändert. Hoffentlich kommt ab Gimp 3.x niemand mehr auf die Idee, die ganze unselige Geschichte mit einer etwas moderneren Webkitgtk-Engine zu wiederholen, die würde mit der Zeit genauso u.a. in Debian vor sich hinverrotten.
Wer nun aber anfangen möchte, über Debian herzuziehen, der sollte seine gerade benutzte Distro einmal auf derartige Abhängigkeiten abklopfen. Einfach in der Paketverwaltung nach Webkit suchen und dann einmal versuchen, diese Engines zu deinstallieren (falls kein Sicherheitssupport für diese bestehen sollte). Aber bitte erst schauen, was dann sonst noch so deinstalliert würde.
Debian hat dieses Problem schon verstanden, nur deshalb weist man so vehement auf Firefox und Chromium als sichere Webbrowser in Debian hin.
ich sehe sowas eher als fundamentales gnu/linux sicherheits-problem in den meisten distros.
es wird immer von hoher sicherheit gesprochen, wenn man jedoch tiefer ins system schaut wird es schnell gruselig.
https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
gleiche frage gilt wenn Firefox ESR zb nicht mehr offiziell weiter gepatcht wird. Ich habe schlichtweg kein gutes Gefühl wenn dann die Distros selbst anfangen sicherheitsupdates manuell nachzufriemeln. M.E. gehöhrt dann eher die nächste ESR-Version Distroseitig angeboten.
Und was machst Du bei Paketen die keine ESR oder Security Fixes anbieten?
Die Aussage man nehme bitte die nächste neue (größere) Version funktioniert leider nur sehr selten. Neue Versionen bringen in der Regel auch neue Abhängigkeiten mit sich deren Auswirkungen durch das Securityteam nicht prüfbar sind.
Aber einen oder mehrere Diff(s) für einen Security Fix einspielen der sich relativ leicht aus den Upstream Commits holen lässt ist das deutlich kleinere Übel. Für neuere Versionen gibt es Backports, hier ist aber auch der Admin verantwortlich dafür, dass es auch dem Updaten wieder rund läuft.
Ich kann jeden der sich über die Problematik mit Security Fixen im Bezug zu Debian beschwert ganz herzlich dazu einladen mal an einem Sprint teilzunehmen und zu versuchen seine Meinung dort zu vertreten. Man wird schnell merken das es kein schwarz/weiß gibt sondern ein vielschichtiges Bunt mit einer klaren konservativen Linie. Im Mittelpunkt steht der Benutzer und die Stabilität.
Hallo,
mir ist das Problem durchaus bewusst.
Der Browser ist jedoch m.E. im Desktop-Betrieb mit die für Angriffe empfindlichste Komponente. Ich frage mich wie man hier ernsthaft von neueren ESR-Versionen SecurityBugs auf alte ESR-Versionen sinnvoll Backporten will ohne ggf. neue Security-Probleme zu öffnen.
Ich fänd es gut wenns für Debian eine einfache Möglichkeit gäb wenn Firefox+Thunderbird in zwei Versionen Verfügbar wäre. Einmal in der Stablen Version wie bisher, und einmal als "mozilla-firefox-new" Package, welches immer ein offiziell supportetes ESR-Package beinhaltet.
Ich weis das das insbesondere bei internen+externen Libs und Plugins etc. ggf regressionen nach sich ziehen würde.
Hier geht es um die Desktop-Sicherheit. Wir wissen inzwischen alle das Geheimdienste und Co die Sicherheit massiv zu unterminieren versuchen - daher sollten solche eventuellen Bugs/Probleme nicht mehr unter den Teppich gekehrt werden.
>> Für neuere Versionen gibt es Backports
Meine Erfahrung mit Debian vor einigen Jahren: Backport für Firefox bzw IceWeasel aktiviert. Firefox/Iceweasel wurden aktualisiert. Thunderbird nicht - Der Debian-Howto gefolgt - es musste ein anderer Backport-Server aktiviert werden - es wurden andere im system inkompatible libs ausgetauscht - bullshitt-bingo-scheisse - wir reden hier von einem "Desktop" - da möchte ich mir frickelkram ersparen.
Und wer garantiert mir dann das die Backports regelmaessig gewartet werden? - wohl niemand mehr.
Dann fahr ich bald besser Firefox/Thunderbird der Distro runterzuwerfen und mir in /home/foobar/bin/ eigene aktuelle Binarys abzulegen
Übrigens - unter Ubuntu14.04 oderso gabs in diesem Fall (manuell installierter Firefox) reproduzierbare adobe-flash-crashes - wenn man das flash-video auf vollbild gestellt hat, sonst nicht - Frickelei hoch 3!
Firefox und Thunderbird gibt es nicht im Backports Repository sondern "nur" über die Securityupdates. Dies ist eine Besonderheit da beide Pakete im eigentlichen Sinne neue Versionen sind und somit eigentlich nicht in den Security Zweig gehören.
Du hast scheinbar ein anderes Verständnis von Mozilla ESR Versionen wie mir scheint. Es gibt da nicht mehrere Versionen, es gibt immer nur eine und diese Version ist die von Mozilla unterstützte Version. Insofern benutzt Du diese oder lässt es. Diese wird übrigens alle 6 Wochen sehr regelmäßig veröffentlicht.
Welche zwei Versionen soll es denn geben? Es gibt beim Firefox die ESR Versionen die faktisch nur Security und Regression Updates, beim Thunderbird gibt es in Anlehnung der Firefox ESR Version einen ähnlichen Releasezyklus. Und zusätzlich gibt es noch die normalen Entwicklungsreleases. Vom Securityteam werden aber nur die ESR Version vom Firefox bzw. an dessen Anlehnung die Thunderbirdversion eingepflegt. Für mehr Sachen sind auch keine Ressourcen da. Wer trotzdem Bleeding Etch benutzen will kann gerne auf Versionen von Upstream zurück greifen. Wer bei der Pflege der Pakete (und nicht "nur" einen Fix) helfen will ist gerne eingeladen mitzuwirken. In den letzten fünf Jahren ist dies aber nicht einmal in vorgekommen.
Und noch etwas was Du vermutlich nicht gerne hören wirst, Backports gehört genauso wie contrtib oder non-free nicht zum offiziellen Debian, das es das doch gibt ist eine freiwillige Zusatzleistung der Maintainer. Man kommt nicht umhin sich mal mit dem Wesen und der Philosophie von Debian zu beschäftigen bevor man Kritik üben will.
Ach ja, Ubuntu != Debian
beschäftige Dich einfach mit den Release Zyklen von Firefox ESR und Du wirst feststellen das in 1-2 Jahren neuere Firefox ESR versionen von Mozilla betrieben werden als die jetzt in Debian 9 mitgelieferte. Die Frage ist ob dann noch die dann veraltete Firefox ESR version sinnvoll gepatcht werden kann, oder ob es nicht sinnvoller wäre ein neues Package für die dann aktuelle Firefox-ESR version anzubieten.
m.e wäre dann aus sicherheitssicht ein upgrade auf firefox esr 58.x sinnvoller - und zwar offiziell und nicht via 'freiwilligem' backport gefrickel.
---------
Schön das du die aus Sicherheitssicht fragwürdigen Backport-Qualität hier bestätigst.
---------
Das Ubuntu != Debian ist mir nichts neues - das Beispiel zeigt mir dennoch das Linux nach wie vor frickelig im Desktopbdtrieb sein kann.
In Debian Wheezy LTS ist das nun so, hier wird nun Firefox 52.x ESR ausgeliefert:
https://lists.debian.org/debian-lts-announce/2017/06/msg00019.html
Debian-Entwickler möchten nicht unbedingt das Rad neu erfinden, zudem, wenn man sich mit Upstream ganz gut versteht.
Ja manchmal wird es wirklich gruselig.
Ich wollte gerade Midori 0.5.11 in Debian Stretch nachinstallieren. Synaptic blendet mir dann als zu installierende Abhängigkeit u.a. libwebkitgtk-1.0.0 ein.
Was soll man dazu noch sagen? Ein Midori-Browser wie derjenige in Debian, der libwebkitgtk-1.0.0 zum Webbrowsen benötigt, muss aus Sicherheitsgründen komplett aus dem Main-Repo entfernt werden, zusammen mit libwebkitgtk-1.0.0.
Da haben wir das Webkit-Problem. Absolut grausig.
Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.
Eine derartige Liste gibt es nicht da das Security keine Ausnahmen macht was Softwarepakete angeht. Wenn CVEs bekannt werden dann ordnet das Security Team dies den Paketen zu und bittet zunächst die Paketmaintainer die CVEs zu fixen. Sollte des Paket aber keinen Maintainer besitzen dann springen gerne auch mal andere Maintainer ein und erst ganz zuletzt werden manchen Pakete durch das Security mit Fixes versorgt.
Gibt es für ein Paket keine Fixes und die Sicherheitsprobleme sind gravierend wird das Paket aus der Distribution entfernt.
Die gibt es. Du musst das Paket debian-security-support nachinstallieren und danach check-support-status in einem Konsolenfenster ausführen. Etwaige installierte und nicht betreute Pakete werden dann angezeigt.
Ich erhalte unter Debian Stretch folgende Ausgabe:
joeuser:~$ check-support-status
Eingeschränkte Versorgung mit Sicherheitsaktualisierungen für eines oder mehrere Pakete
Leider war es nötig, die Versorgung mit Sicherheitsaktualisierungen
für einige Pakete einzuschränken.
Davon sind die folgenden auf diesem System gefundenen Pakete betroffen:
* Quelle:qtwebkit-opensource-src
Einzelheiten: No security support upstream and backports not feasible, only for use on trusted content
Betroffenes Binärpaket:
- libqt5webkit5:amd64 (installierte Version: 5.7.1+dfsg-1)
Nun ja, dies heißt aber immer noch nicht das es keine Fixes geben wird. Der Hinweis weißt darauf hin das es von Upstream keinen Support für dieses Paket gibt. Andere Distributionen haben dieses Problem auch und Fixes machen dann gerne mal die Runde.
Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.
Gibt es irgendwo eine Liste an Paketen, die nicht vom Security Team betreut werden? Würde mich sehr interessieren, welche der Pakete aus dem Repository nicht von Debian nicht Sicherheits-Updates versorgt werden. Das Security-Team war immer ein Grund, warum ich Debian anderen Distributionen Vorzug, auch für den Desktop.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Leider gibt es diese nur für Ubuntu, sogar als Terminalbefehl selbst dort. In Debian habe ich so eine noch nie gesehen, die scheinen es wohl nicht für nötig zu halten ihre Nutzer darüber zu informieren, stattdessen wird das Paket von heute auf morgen lieber ohne Ankündigung eingestellt.
Man möge mir das nicht beabsichtigte Spamen bitte verzeihen, die Webseite ist nicht gerade für Mobilgeräte optimiert worden
Übersetzt:
„Und wieder hat mal jemand ne Web Engine gemacht, die sich nur sehr schwer auf stabilen Distri updaten lässt, weil kompliziert mit GTK vernetzt. Die Schuld gebe ich aber Debian, nicht WebkitGTK/Qt. Ach, wie schade.“
Derjenige, der die Distribution anbietet, steht primär in der Verantwortung. Mein Posting bezog sich nicht nur auf Debian.
Was hindert Debian, Ubuntu, OpenSuse oder Mint daran, Konqueror, Qupzilla, Epiphany-Browser oder Midori beim Bekanntwerden von remote ausnutzbaren Sicherheitslücken aus einer Debian-Distro mit dem nächsten Point-Release herauszunehmen, wenn man diese Lücken nicht patchen kann oder der Aufwand dafür zu groß ist?
Bei Owncloud in Ubuntu war es ja auch möglich, mit Rekonq verfuhr Debian aus anderen Gründen geradezu knallhart.
Ein remote ausnutzbares Sicherheitsloch? Keiner kann oder will patchen? Mein lieber Maintainer, dort ist die Tür für Dein Paket. Raus damit!
Der Text stimmt natürlich so nicht, ich habe mich oben an einem Punkt verschrieben.
Natürlich ist jede Distro für sich selbst verantwortlich ist und Webbrowser mit Sicherheitslücken, die remote ausnutzbar sind, sollten am Besten aus einer Distribution herausgenommen werden.
Debian ist davon nicht alleine betroffen.
OpenSuse z.B. hat gerade Seamonkey mit im Angebot, obgleich Seamonkey mehrere Versionen hinter einer sicheren Firefox- oder Firefox-ESR-Version hinterherhinkt. Mit Epiphanybrowser hat OpenSuse genau das gleiche Problem wie Debian.
Die Beispielliste über die meisten Distros hinweg ist hier riesengroß und keinesfalls auf Debian beschränkt.
Das umrissene Problem ist real. Mit "Mir doch egal, ob überhaupt gepatcht wird." kommt man da nicht weiter.
Ich habe nicht gesagt, dass es mir egal ist. Aber wenn jemand eine Web Engine baut, die den halben GTK Stack neu haben will bei einer neuen Version, wie soll Debian das dann patchen?
Aber du hast Recht, sie hätten das Ding einfach entfernen sollen. Nur dann ist das Problem, dass z.B. viele einfache Programme nicht mehr gehen, weil sie Webkit fürs Rendern benutzen.
"Nur dann ist das Problem, dass z.B. viele einfache Programme nicht mehr gehen, weil sie Webkit fürs Rendern benutzen."
Genau das ist das Hauptproblem. Man ruft ein Programm auf und weiß gar nicht, dass eine solche unsichere Webkit-Engine mitbenutzt wird.
Die Distribution müsste dann KDE- oder GTK-/Gnome-Programme so kompilieren, dass diese Webkit- oder Khtml-Engines nur lokale Inhalte anzeigen. Gnomes Epiphany-Browser z.B. dürfte IMO unter Debian gar nicht ins Internet gelangen, zumal sich hier noch nicht einmal mehr Javascript in der GUI abschalten lässt.
Und da fängt dann eine mögliche Bevormundung des Nutzers an, die Debian eher ablehnt. Was bleibt, ist dem Nutzer zu sagen, dass er unter Debian machen kann, was er will, auch mit unsicherer Software im Internet herumsurfen, wenn er das so möchte, nur hat es Debian vorher immerhin deutlich gesagt, dass das in punkto Sicherheit ganz großer Mist ist.
Das ist etwa so, als würde man mit dem alten Internet Explorer oder einem alten T-Online-Browser auf einem noch "unterstützten" Windows im Internet herumsurfen.
Keine Distribution bekommt es momentan hin, die Webkit- und Khtml-Engines etwas älterer KDE- und Gnome-Desktops so anzubieten, dass man mit diesen sicher im Internet surfen kann. Die einzige Ausnahme sind regelmäßig aktualisierte Distributionen wie Fedora oder Rolling-Release-Distros.
Nur: Man weiß, dass Webkit-Upstream ältere Webkitversionen nicht mehr supportet. Wieso ruft man dann für das Anzeigen von Internetinhalten unter Debian nicht einfach erst einmal standardmäßig Firefox oder Chromium auf (was natürlich als Option überschreibbar bzw. veränderbar bliebe)?