debianforum.de

Benutzt hier jemand ernsthaft den Chromium?

https://tracker.debian.org/pkg/chromium

Auch wenn ev. nicht jede Lücke sofort zum Gau führt ... das klingt nicht gesund:

" 46 security issues in buster high
There are 46 open security issues in buster.
46 important issues:

CVE-2020-6510: Heap buffer overflow in background fetch in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6511: Information leak in content security policy in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
CVE-2020-6512: Type Confusion in V8 in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6513: Heap buffer overflow in PDFium in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted PDF file.
CVE-2020-6514: Inappropriate implementation in WebRTC in Google Chrome prior to 84.0.4147.89 allowed an attacker in a privileged network position to potentially exploit heap corruption via a crafted SCTP stream.
CVE-2020-6515: Use after free in tab strip in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6516: Policy bypass in CORS in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
CVE-2020-6517: Heap buffer overflow in history in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6518: Use after free in developer tools in Google Chrome prior to 84.0.4147.89 allowed a remote attacker who had convinced the user to use developer tools to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6519: Policy bypass in CSP in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to bypass content security policy via a crafted HTML page.
CVE-2020-6520: Buffer overflow in Skia in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6521: Side-channel information leakage in autofill in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page.
CVE-2020-6522: Inappropriate implementation in external protocol handlers in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page.
CVE-2020-6523: Out of bounds write in Skia in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6524: Heap buffer overflow in WebAudio in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6525: Heap buffer overflow in Skia in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6526: Inappropriate implementation in iframe sandbox in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page.
CVE-2020-6527: Insufficient policy enforcement in CSP in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to bypass content security policy via a crafted HTML page.
CVE-2020-6528: Incorrect security UI in basic auth in Google Chrome on iOS prior to 84.0.4147.89 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.
CVE-2020-6529: Inappropriate implementation in WebRTC in Google Chrome prior to 84.0.4147.89 allowed an attacker in a privileged network position to leak cross-origin data via a crafted HTML page.
CVE-2020-6530: Out of bounds memory access in developer tools in Google Chrome prior to 84.0.4147.89 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted Chrome Extension.
CVE-2020-6531: Side-channel information leakage in scroll to text in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
CVE-2020-6532:
CVE-2020-6533: Type Confusion in V8 in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6534: Heap buffer overflow in WebRTC in Google Chrome prior to 84.0.4147.89 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
CVE-2020-6535: Insufficient data validation in WebUI in Google Chrome prior to 84.0.4147.89 allowed a remote attacker who had compromised the renderer process to inject scripts or HTML into a privileged page via a crafted HTML page.
CVE-2020-6536: Incorrect security UI in PWAs in Google Chrome prior to 84.0.4147.89 allowed a remote attacker who had persuaded the user to install a PWA to spoof the contents of the Omnibox (URL bar) via a crafted PWA.
CVE-2020-6537:
CVE-2020-6538:
CVE-2020-6539:
CVE-2020-6540:
CVE-2020-6541:
CVE-2020-6542:
CVE-2020-6543:
CVE-2020-6544:
CVE-2020-6545:
CVE-2020-6546:
CVE-2020-6547:
CVE-2020-6548:
CVE-2020-6549:
CVE-2020-6550:
CVE-2020-6551:
CVE-2020-6552:
CVE-2020-6553:
CVE-2020-6554:
CVE-2020-6555:........................"

Ist ja leider nicht nur momentan so.

mcb hat geschrieben:

14.08.2020 15:39:03

Benutzt hier jemand ernsthaft den Chromium?

Ist dass deine eigentliche Frage? Falls ja, kannst du +1 rechnen.

mcb hat geschrieben:

14.08.2020 15:39:03

Benutzt hier jemand ernsthaft den Chromium?

Ich nicht. Ich vertraue weder dem Browser [1], noch den Fähigkeiten des QA-Teams*, welches den Browser in Debian betreut.


[1] viewtopic.php?f=29&t=164083
(Disclaimer: Meinen Kenntnisstand habe ich seit diesem 3 Jahre alten Thread nicht aktualisiert und einen Bugreport habe ich auch nie abgeetzt.)

*) basierend auf direktem Kontakt zwecks eines FTBFS-Problems

cronoik hat geschrieben:

14.08.2020 15:55:03

mcb hat geschrieben:

14.08.2020 15:39:03

Benutzt hier jemand ernsthaft den Chromium?

Ist dass deine eigentliche Frage? Falls ja, kannst du +1 rechnen.

Und ein Dutzend, die sich davon distanzieren und ihre Lieblingsbrowser (Firefox, Waterfox, Palemoon, Lynx) angeben.

War ev. ne blöde Frage ? Ich würde ihn ja als Zweitbrowser benutzen - nur er hat mir meist zuviele offene Lücken. Und Chrome ist ja auch nicht der Weisheit letzter Schluß (Bitte nicht steinigen)

OK erledigt ...

Das ist keine bloede Frage, aber was hast du jetzt davon wenn du weist dass ich Chromium benutze? Deshalb fragte ich ob du nicht eigentlich etwas anderes wissen willst. Beispielsweise ob das noch abgesichert wird oder die Nutzung eingeschraenkt wird oder ich meine Tabletten nicht mehr nehme.

cronoik hat geschrieben:

14.08.2020 17:15:00

Das ist keine bloede Frage, aber was hast du jetzt davon wenn du weist dass ich Chromium benutze? Deshalb fragte ich ob du nicht eigentlich etwas anderes wissen willst. Beispielsweise ob das noch abgesichert wird oder die Nutzung eingeschraenkt wird oder ich meine Tabletten nicht mehr nehme.

Stimmt davon habe ich nichts. Da hast du völlig recht.... Ich wundere mich halt das der immer so sehr bei den Sicherheitspatches hinter her hingt (Stört das viele Leute nicht?). Kann man meiner Meinung nach gar nicht nehmen.

Ergo ich suche nach Möglichkeit einen "Chromium" mit "wenig" google der recht zeitnah aktualisiert wird (wie z.B. der mitgelieferte Firefox ESR). Gibt es sowas für Debian Buster ?

mcb hat geschrieben:

14.08.2020 20:02:10

"Chromium" mit "wenig" google

Ist das sowas wie "fettarme Butter"?

Hätte ich halt nicht gedacht das es mit Browsern unter Linux (mangels Auswahl) schwierig ist. Na ja bin seit ein paar Wochen von itunes/foobar zu cmus umgezogen

mcb hat geschrieben:

14.08.2020 20:02:10

Stimmt davon habe ich nichts. Da hast du völlig recht.... Ich wundere mich halt das der immer so sehr bei den Sicherheitspatches hinter her hingt (Stört das viele Leute nicht?). Kann man meiner Meinung nach gar nicht nehmen.

Wenn dich das schon stört, dann schau dir den Firefox am Besten erst gar nicht an.

Tintom hat geschrieben:

14.08.2020 20:37:27

mcb hat geschrieben:

14.08.2020 20:02:10

Stimmt davon habe ich nichts. Da hast du völlig recht.... Ich wundere mich halt das der immer so sehr bei den Sicherheitspatches hinter her hingt (Stört das viele Leute nicht?). Kann man meiner Meinung nach gar nicht nehmen.

Wenn dich das schon stört, dann schau dir den Firefox am Besten erst gar nicht an.

Wieso ? Hier läuft FF 80 (beta 6)

Mozilla hat gerade ein Viertel seiner Mitarbeiter gefeuert. Die meisten Bugs werden aber meist von den eigenen Mitarbeitern gefunden. Wirkt für künftige Versionen nicht unbedingt vertrauenserweckend.

Anmerkung: Ich habe mir die CVE-Chromiumsachen nicht im Detail angesehen und die Frage ist auch ob meine Faehigkeiten eine Bewertung zulassen.

mcb hat geschrieben:

14.08.2020 20:02:10

Stimmt davon habe ich nichts. Da hast du völlig recht.... Ich wundere mich halt das der immer so sehr bei den Sicherheitspatches hinter her hingt (Stört das viele Leute nicht?). Kann man meiner Meinung nach gar nicht nehmen.

Also hier stellt sich die Frage was es genau fuer Sicherheitspatches sind. Sind die tatsaechlich kritisch oder als weniger kritisch einzustufen (zum Vertiefen[1]). Angenommen es ist alles in Ordnung, dann sind die von dir gelisteten Sachen als nicht kritisch eingestuft worden. Falls nicht, dann muss hier bei Security mal nachgehaken werden (oder besser selbst Maintainer werden und unterstuetzen), da Chromium auch in den Releasenotes empfohlen wird [2].

mcb hat geschrieben:

14.08.2020 20:02:10

Ergo ich suche nach Möglichkeit einen "Chromium" mit "wenig" google der recht zeitnah aktualisiert wird (wie z.B. der mitgelieferte Firefox ESR). Gibt es sowas für Debian Buster ?

Ich zeig mal auf snap [3], bei den Konkurrenten wirst du bestimmt auch fuendig.

[1] https://www.debian.org/security/faq#cvedsa
[2] https://www.debian.org/releases/stable/ ... r-security
[3] https://snapcraft.io/chromium

Du legst dein Augenmerk auf die falschen Dinge. Man sollte sich angesichts der genutzten Technologien im Internet, samt der äusserst wechselhaften Entwicklung keine Hoffnungen machen, dass Browser jemals nicht Unmengen an Sicherheitslücken haben werden. Bei Browsern ist das quasi der Status Quo, und daher weder überraschend noch wirklich besorgniserregend. Ausser vielleicht unter Windows, wo ein unachtsamer Klick oder Download die nächste Katastrophe einleiten kann. Glücklicherweise nutzen wir jedoch GNU/Linux, womit prinzipiell ganz andere Bedingungen gegeben sind, inwiefern akute Sicherheitslücken überhaupt greifen bzw. ob man wirklich von einer Bedrohung sprechen kann. Nicht zuletzt ist auch das Browser eigene Sandboxing auf Basis des Linux-Kernel, deutlich umfangreicher und erfahrungsgemäß auch wirksamer, weshalb einem hier nicht mal eben alles um die Ohren fliegt, nur weil der Browser der Wahl mal wieder Sicherheitslücken hat. Und wem das nicht ausreicht, der kann zusätzlich auf weitere Optionen wie Firejail oder AppArmor zurückgreifen, um die Isolation diverser Programme inkl. Browser nochmal deutlich zu verschärfen. Sprich, Du machst Dir zu viele Sorgen, wobei das fixen der Sicherheitslücken je nach Komplexität auch seine Zeit kostet, woran sich jeder gerne beteiligen darf.

Ich für meinen Teil habe mich von den großen Browsern verabschiedet, da mir die Entwicklung zunehmend missfällt. Nicht nur das man es weitgehend mit enormer Bloatware zutun hat, nein, auch die politische Führung sehe ich angesichts dubioser Funktionalitäten mit Sorge, wenn man sowohl bei Firefox als auch Chromium hinsichtlich der Konfiguration, unzähligen Mist abwürgen muss damit die Browser endlich mal die Klappe halten und nur noch tun was sie regulär ausschließlich sollten. Daher bin ich seit geraumer Zeit sehr zufrieden mit Epiphany (Gnome-Web), habe nun einen extrem schlanken Browser der sich auf das wesentliche konzentriert, und das ohne mich mit jeder neuen Version mit lästigen Beigaben zu beglücken. Ein Browser sollte ab Werk vertrauenswürdig sein, und dem Nutzer nicht noch in Sachen Datenschutz und Privatsphäre in den Rücken fallen.

fossonly hat geschrieben:

15.08.2020 17:36:32

Du legst dein Augenmerk auf die falschen Dinge. Man sollte sich angesichts der genutzten Technologien im Internet, samt der äusserst wechselhaften Entwicklung keine Hoffnungen machen, dass Browser jemals nicht Unmengen an Sicherheitslücken haben werden.
[...]
Daher bin ich seit geraumer Zeit sehr zufrieden mit Epiphany (Gnome-Web), habe nun einen extrem schlanken Browser der sich auf das wesentliche konzentriert, und das ohne mich mit jeder neuen Version mit lästigen Beigaben zu beglücken.

Das wäre dann die Vogel-Strauß-Taktik: Die Augen vor Sicherheitslücken verschließen in dem man sich einredet es gäbe keine.

Debian hat vor (1, 2, 3, ?) Releases nach langer Diskussion den fundamentalen Standpunkt "es gibt keine neue Software für stable" für Webbrowser aufgeweicht. Damals stand man vor der Entscheidung: Entweder liefert man überhaupt keinen Webbrowser aus oder man weicht zugunsten der Systemsicherheit von dem Standpunkt ab und macht für die ESR-Pakete eine Ausnahme:

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security hat geschrieben: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.

Hätte man ein vergleichbares Produkt im Repo, wäre man nicht diesen drastischen Schritt gegangen. Ergo bedeutet das für mich, dass alle Browser mit Ausnahme der oben genannten ein noch größeres Risiko darstellen.

Tintom hat geschrieben:

14.08.2020 21:09:00

Mozilla hat gerade ein Viertel seiner Mitarbeiter gefeuert. Die meisten Bugs werden aber meist von den eigenen Mitarbeitern gefunden. Wirkt für künftige Versionen nicht unbedingt vertrauenserweckend.

Ja, "die Gehälter für ihre 1000 Mitarbeiter haben 2018 zusammen 286 Millionen Dollar betragen. Jetzt haben sie einen frischen Deal mit Google über 450 Millionen Dollar pro Jahr gemacht.

Äh, ... an welcher Stelle kommt da eine Geldknappheit ins Spiel?" ... https://blog.fefe.de/?ts=a1c8b564

Ev. sollte mozilla ab und an auf seine Nutzer hören, dann wäre der Marktanteil auch höher (meine Meinung)

cronoik hat geschrieben:

15.08.2020 06:12:25

................ zeitnah aktualisiert wird (wie z.B. der mitgelieferte Firefox ESR). Gibt es sowas für Debian Buster ?

Ich zeig mal auf snap [3], bei den Konkurrenten wirst du bestimmt auch fuendig.

[1] https://www.debian.org/security/faq#cvedsa
[2] https://www.debian.org/releases/stable/ ... r-security
[3] https://snapcraft.io/chromium
[/quote]

Ja 2 hatte ich vor der Installation gelesen und bin von der Umsetzung entäuscht. Mit Firefox ESR funktioniert es gut, mit Chromium strenggenommen nicht.

Snap ? Ich schaue mal ob ich ein Appimage finde, mir würde auch ein tar reichen, wie bei Firefox oder Tor

Letzte möglichkeit ich kompiliere selbst ???

cronoik hat geschrieben:

15.08.2020 06:12:25

Angenommen es ist alles in Ordnung, dann sind die von dir gelisteten Sachen als nicht kritisch eingestuft worden. Falls nicht, dann muss hier bei Security mal nachgehaken werden (oder besser selbst Maintainer werden und unterstuetzen), da Chromium auch in den Releasenotes empfohlen wird [2].
[..]
[2] https://www.debian.org/releases/stable/ ... r-security

Auf diese Sicherheitsunterstützung von Chromium in Debian würde ich nicht viel geben. Wie gesagt, der Code wie er in Debian vorliegt war vor drei Jahren unverständlich und die "Maintainance" des QA-Teams scheint sich darauf zu beschränken, blind neuen zerwürgten Code ins Debian-Repo zu kippen und dann den Compiler anzuwerfen. Es wurden zu Wheezy-Zeiten nicht mal FTBFS-Probleme abseits von x86 behandelt (irgendwie hatten sie es trotzdem geschafft, Binärpakete für armel/hf anzubieten, die aber nach Hinweis auf das FTBFS-Problem entfernt wurden, offenbar ohne sich näher mit den Gründen zu beschäftigen).
Da habe ich beim Firefox-Team in Debian einen ganz anderen Eindruck. Dort werden selbst einige der datenschutztechnischen Experimente die Mozilla den Usern gen mal unterschiebt rausgefiltert. Dass Mozilla selbst jetzt ausgerechnet beim Sicherheits-Team spart ist dem natürlich nicht zuträglich.

cronoik hat geschrieben:

15.08.2020 06:12:25

Ich zeig mal auf snap

Snap, Appimage und Konsorten sind als Freemdquellen zu werten. Klar, kann man machen. Aber man muss sich dann eben immer überlegen, ob man dem Anbieter vertraut. Und das ist ein technisch tieferes Vertrauen als bei "normalen" Fremdquellen, denn in diesen Images stecken nicht nur die Pakete die man als Enduser eigentlich will, sondern auch noch einige Libs, die der Fremdanbieter ebenfalls warten muss.
Traue ich es also dem Fremdanbieter zu, nicht nur $Browser zu warten, sondern auch $LibABC bis $LibXYZ? In Debian gibt es dafür ~1000 Leute. Wieviele hat der Fremdanbieter?

fossonly hat geschrieben:

15.08.2020 17:36:32

Ich für meinen Teil habe mich von den großen Browsern verabschiedet, da mir die Entwicklung zunehmend missfällt. Nicht nur das man es weitgehend mit enormer Bloatware zutun hat, nein, auch die politische Führung sehe ich angesichts dubioser Funktionalitäten mit Sorge, wenn man sowohl bei Firefox als auch Chromium hinsichtlich der Konfiguration, unzähligen Mist abwürgen muss damit die Browser endlich mal die Klappe halten und nur noch tun was sie regulär ausschließlich sollten. Daher bin ich seit geraumer Zeit sehr zufrieden mit Epiphany (Gnome-Web), habe nun einen extrem schlanken Browser der sich auf das wesentliche konzentriert, und das ohne mich mit jeder neuen Version mit lästigen Beigaben zu beglücken. Ein Browser sollte ab Werk vertrauenswürdig sein, und dem Nutzer nicht noch in Sachen Datenschutz und Privatsphäre in den Rücken fallen.

Epiphany basiert auf Webkit. Das bekommt aber in Debian keine Sicherheitsupdates, weil diese sich nicht sinnvoll zurückportieren lassen. Daher ist Webkit in Debian, wie in vielen anderen Distributionen auch als unsicher anzusehen. [1] Von deinem schlanken und vermeintlich sicheren Webkit-Browser hast du also nichts, wenn die darunterliegende Webkit-Engine bereits anfängt unangenehm zu riechen.
Einen Webkit-Browser unter Debian würde ich nur unter Unstable und vielleicht noch Testing als sicher ansehen, aber nicht unter Stable.


[1] https://blogs.gnome.org/mcatanzaro/2016 ... y-updates/

hikaru hat geschrieben:

16.08.2020 10:00:13

[...] Traue ich es also dem Fremdanbieter zu, nicht nur $Browser zu warten, sondern auch $LibABC bis $LibXYZ? In Debian gibt es dafür ~1000 Leute. Wieviele hat der Fremdanbieter?

Ich sehe deinen ganzen Beitrag als Bereicherung zu meinem an und will nur die Luecke fuellen. Im Fall von Chromium ist es Canonical und die liefern Chromium wohl nur noch als snap aus [1].

[1] https://www.golem.de/news/eoan-ermine-u ... 478-2.html

Ja bei dem Chromium-Snap wird viel aufwand getrieben um es aktuel zu halten.

- ich halte aber gar nichts von snap, also muß ich mir was anderes überlegen.

@Tintom
Ich bin lediglich Realist und stecke auch nicht den Kopf in den Sand, sondern akzeptiere nur den unabänderlichen Fakt, dass heute auf jeden Browser hunderte an Sicherheitslücken pro Jahr kommen, die seitens der Entwickler je nach Komplexität kaum zeitnah gefixt werden können angesichts der Masse. Und darauf kommen dann noch die Prozesse diese Sicherheitsupdates entsprechend zu verteilen, was für sich nochmals Zeit kostet. Das ist heutzutage ein Wettlauf der je nach Browser kaum gewonnen werden kann, weshalb moderne Browser aus gutem Grund auf das Sandboxing seitens der Betriebssysteme zurückgreifen, damit die Angriffsfläche im Ernstfall eben deutlich minimiert ist. Wer zudem aus noch besseren Gründen auf Javascript verzichtet, hat erfahrungsgemäß noch weitaus weniger Sorgen mit Sicherheitslücken.

hikaru hat geschrieben:

16.08.2020 10:00:13

Epiphany basiert auf Webkit. Das bekommt aber in Debian keine Sicherheitsupdates, weil diese sich nicht sinnvoll zurückportieren lassen. Daher ist Webkit in Debian, wie in vielen anderen Distributionen auch als unsicher anzusehen. [1] Von deinem schlanken und vermeintlich sicheren Webkit-Browser hast du also nichts, wenn die darunterliegende Webkit-Engine bereits anfängt unangenehm zu riechen.
Einen Webkit-Browser unter Debian würde ich nur unter Unstable und vielleicht noch Testing als sicher ansehen, aber nicht unter Stable.


[1] https://blogs.gnome.org/mcatanzaro/2016 ... y-updates/

Du stützt deine Argumentation auf hoffnungslos veraltete Informationen. Es geht hier um vier Jahre was in Sachen Software eine Ewigkeit ist. Die zugrundeliegenden Probleme der Vergangenheit sind auch längst adressiert worden.

Siehe:
https://security-tracker.debian.org/tra ... webkit2gtk

Und wie man auch deinem Link entnehmen konnte, gab es ja so einige Mängel als auch Informationen hinsichtlich zukünftiger Verbesserungen. Die interne Struktur seitens WebKit2GTK hat sich seit jeher deutlich geändert, womit unter anderem auch vieles an Code in separate Module ausgelagert wurde, was zugleich ermöglicht hat eine sehr granulierte Isolation mithilfe von Bubblewrap (ähnlich wie unter Chromium) herzustellen. Dein Link stammte ebenfalls vom maßgeblich dafür verantwortlichen Entwickler, der die ganzen Verbesserungen erfreulich und regelmäßig detailliert veröffentlicht. Und wie Du dem Security-Tracker von Debian entnehmen kannst, ist hier alles von Debian-Stable bis Debian-Unstable gleichermaßen mit Sicherheitsupdates versorgt. Man kommt selbst über die Backports an moderne Versionen von WebKit2GTK. Daher sollten die Bedenken heute eigentlich nicht länger bestehen.

fossonly hat geschrieben:

16.08.2020 18:48:10

Du stützt deine Argumentation auf hoffnungslos veraltete Informationen. Es geht hier um vier Jahre was in Sachen Software eine Ewigkeit ist. Die zugrundeliegenden Probleme der Vergangenheit sind auch längst adressiert worden.

Siehe:
https://security-tracker.debian.org/tra ... webkit2gtk

Danke für den Hinweis! Das scheint seit Buster neu zu sein. Nutzt du aufgrund dieser Änderung nun Epiphany oder hast du den schon vorher verwendet?
Und kannst du abschätzen, wie sich damit allgemein die Sicherheitslage von Webkit-Browsern verändert hat? Sprich: Wieviel Anteil hat Webkit an der Sicherheit und wieviel der Browser selbst? epiphany-browser hat ja inzwischen selbst ein Update unter Buster bekommen, aber z.B. midori nicht

fossonly hat geschrieben:

16.08.2020 18:48:10

Daher sollten die Bedenken heute eigentlich nicht länger bestehen.

Nun ja, wie du https://security-tracker.debian.org/tra ... ny-browser entnehmen kannst, ist dein bevorzugter Browser angeblich noch anfällig für eine SSL-Lücke von vor 6 (!) Jahren. Ich verstehe aber nicht so recht warum, denn die Bibliotheken mit denen das Paket gebaut wird, sind seit Jahren gefixt.

Habe grad nochmal geschaut:

zur Zeit über 60 Lücken, das bringt es nicht ... schade.

https://security-tracker.debian.org/tra ... e/chromium

Wow:

action needed
100 security issues in sid high
100 security issues in buster high
100 security issues in bullseye high
lintian reports 673 errors and 15 warnings

https://tracker.debian.org/pkg/chromium