[gelöst] Chromium
[gelöst] Chromium
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.
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.
Zuletzt geändert von mcb am 28.08.2020 09:12:54, insgesamt 1-mal geändert.
-
- Beiträge: 2049
- Registriert: 18.03.2012 21:13:42
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Chromium
Ist dass deine eigentliche Frage? Falls ja, kannst du +1 rechnen.
Hilf mit unser Wiki zu verbessern!
Re: 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
Re: Chromium
Und ein Dutzend, die sich davon distanzieren und ihre Lieblingsbrowser (Firefox, Waterfox, Palemoon, Lynx) angeben.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Chromium
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 ...
OK erledigt ...
-
- Beiträge: 2049
- Registriert: 18.03.2012 21:13:42
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Chromium
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.
Hilf mit unser Wiki zu verbessern!
Re: Chromium
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.cronoik hat geschrieben:14.08.2020 17:15:00Das 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.
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 ?
Re: Chromium
Ist das sowas wie "fettarme Butter"?
Re: Chromium
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
Re: Chromium
Wenn dich das schon stört, dann schau dir den Firefox am Besten erst gar nicht an.mcb hat geschrieben:14.08.2020 20:02:10Stimmt 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.
Re: Chromium
Wieso ? Hier läuft FF 80 (beta 6)Tintom hat geschrieben:14.08.2020 20:37:27Wenn dich das schon stört, dann schau dir den Firefox am Besten erst gar nicht an.mcb hat geschrieben:14.08.2020 20:02:10Stimmt 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.
Re: Chromium
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.
-
- Beiträge: 2049
- Registriert: 18.03.2012 21:13:42
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Chromium
Anmerkung: Ich habe mir die CVE-Chromiumsachen nicht im Detail angesehen und die Frage ist auch ob meine Faehigkeiten eine Bewertung zulassen.
[1] https://www.debian.org/security/faq#cvedsa
[2] https://www.debian.org/releases/stable/ ... r-security
[3] https://snapcraft.io/chromium
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:10Stimmt 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.
Ich zeig mal auf snap [3], bei den Konkurrenten wirst du bestimmt auch fuendig.mcb hat geschrieben:14.08.2020 20:02:10Ergo 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 ?
[1] https://www.debian.org/security/faq#cvedsa
[2] https://www.debian.org/releases/stable/ ... r-security
[3] https://snapcraft.io/chromium
Hilf mit unser Wiki zu verbessern!
Re: 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.
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.
Re: Chromium
Das wäre dann die Vogel-Strauß-Taktik: Die Augen vor Sicherheitslücken verschließen in dem man sich einredet es gäbe keine.fossonly hat geschrieben:15.08.2020 17:36:32Du 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.
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:
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.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.
Re: Chromium
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.Tintom hat geschrieben:14.08.2020 21:09:00Mozilla 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.
Ä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)
Re: Chromium
Ich zeig mal auf snap [3], bei den Konkurrenten wirst du bestimmt auch fuendig.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 ?
[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 ???
Re: Chromium
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).cronoik hat geschrieben:15.08.2020 06:12:25Angenommen 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
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.
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?
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.fossonly hat geschrieben:15.08.2020 17:36:32Ich 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.
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/
-
- Beiträge: 2049
- Registriert: 18.03.2012 21:13:42
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Chromium
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].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?
[1] https://www.golem.de/news/eoan-ermine-u ... 478-2.html
Hilf mit unser Wiki zu verbessern!
Re: Chromium
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.
- ich halte aber gar nichts von snap, also muß ich mir was anderes überlegen.
Re: Chromium
@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.
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.
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.
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.hikaru hat geschrieben:16.08.2020 10:00:13Epiphany 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/
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.
Re: Chromium
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?fossonly hat geschrieben:16.08.2020 18:48:10Du 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 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
Re: Chromium
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.fossonly hat geschrieben:16.08.2020 18:48:10Daher sollten die Bedenken heute eigentlich nicht länger bestehen.
Re: Chromium
Habe grad nochmal geschaut:
zur Zeit über 60 Lücken, das bringt es nicht ... schade.
https://security-tracker.debian.org/tra ... e/chromium
zur Zeit über 60 Lücken, das bringt es nicht ... schade.
https://security-tracker.debian.org/tra ... e/chromium
Re: [gelöst] 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
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