65 existiert schon seit dem 20.02. in unstable:
https://tracker.debian.org/pkg/chromium-browser
Wie man sieht, ist sogar schon 66 längst in unstable.
Die Maintainer werden sich sicher was bei denken und ich würde ihnen mehr vertrauen als Google.
(Außerdem: wer einen browser von google verwendet, braucht sich um Sicherheit eh keine Gedanken zu machen... )
Sicherheitsupdate für Chromium.
-
- Beiträge: 385
- Registriert: 16.06.2017 09:52:36
Re: Sicherheitsupdate für Chromium.
Ich bezweifele weder, dass die Maintainer sich was denken, noch, dass sie sehr bemüht sind. Es sieht mir eher so aus, als ob sie nicht hinterherkommen ... ähnlich wie bei Firefox damals.RobertDebiannutzer hat geschrieben:09.04.2018 18:47:27Die Maintainer werden sich sicher was bei denken und ich würde ihnen mehr vertrauen als Google.
Übrigens müssen auch die Maintainer Google vertrauen ... darauf dass Google sämtliche Sicherheitslücken auch deutlich per CVE oder anderweitig dokumentiert, inklusive Patch. Andernfalls müssen sie jegliche Code-Änderung auf eigene Faust darauf hin abgrasen, ob sie vielleicht (auch) eine Sicherheitslücke schließt.
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: Sicherheitsupdate für Chromium.
Unsarkastisch betrachtet ist das völlig korrekt - problematisch sind die datenschutztechnischen Details. Aber Firefox ist da ja auch schwer am aufholen. Die wären in dem Punkt eigentlich heute schon fast gleich unbrauchbar, wenn man Firefox nicht noch so großzügig umkonfigurieren könnte!?RobertDebiannutzer hat geschrieben:09.04.2018 18:47:27(Außerdem: wer einen browser von google verwendet, braucht sich um Sicherheit eh keine Gedanken zu machen... )
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: Sicherheitsupdate für Chromium.
So war das eigentlich nicht gemeint. Zumal seitens Debian nur dann eingegriffen wird, wenn es für Sicherheitslücken noch keine korrigieren Versionen gibt, bzw. wenn das Security-Team selbst Sicherheitslücken findet. Das ist doch an sich etwas Gutes, gerade wenn akut Handlungsbedarf besteht. Und anhand veröffentlichter CVEs ist auch ersichtlich, welche Sicherheitslücken eine besonders hohe Priorität haben. Da wird eher nichts ausgeknobelt.NAB hat geschrieben:09.04.2018 17:32:50Also auf anderen Platformen spielt man einfach eine Version ein, die die bekannten Sicherheitslücken nicht mehr hat, während man bei Debian darauf warten muss, dass das DSA-Team ausgeknobelt hat, ob die Sicherheitslücken für den individuellen Anwendungsfall auch gefährlich sein könnten ... nunja.
Sichert firejail inzwischen eigentlich irgendwie gegen Spectre ab?
Und was Spectre angeht, so ist das eine reine Baustelle für GCC, den Linux-Kernel, und muss via CPU-Microcode bzw. mittels verbesserter CPU-Architektur adressiert werden. Hier wäre Firejail die falsche Adresse. Wobei Firejail ohnehin auf Technologien basiert die der Linux-Kernel zur Verfügung stellt, und damit unmittelbar davon abhängig ist. Mittlerweile existieren ja schon einige wirksame Gegenmaßnahmen, nur Spectre v1 wird auf längere Sicht ein Problem bleiben. Zumal das Problem derart umfassend ist, dass immer wieder neue Angriffsvektoren auftauchen können, wo man kaum drum herum kommt die CPU-Architektur zu ändern. Nur das ist auch wieder so eine Sache, weil das zugrundeliegende Problem, die spekulative Ausführung, insbesondere für ein erhebliches Plus an Geschwindigkeit sorgt, und nicht mal eben komplett ausgeschaltet werden kann. Daher sehen die Gegenmaßnahmen im Linux-Kernel unter anderem auch vor, besondere Bereiche die davon betroffen sind, von der spekulativen Ausführung auszuschließen.