Wenn ich in Arch-Linux beispielsweise "Okular" installieren möchte, würde "Strigi" und "Zeitgeist" als Abhängigkeit installiert werden. Ich möchte diese Tracker aber nicht einsetzen. Warum benötigt ein Dokumentenbetrachter unbedingt einen Meta-Tracker? Ein Meta-Tracker sollte doch eher optional integriert sein. Sollten die KDE-Applications nicht vom KDE-Desktop Plasma unabhängig sein? Die Trennung erscheint mir nicht konsequent und granular. Oder liegt das an einer groben, pauschalen Packetierung der Distribution?
Installiert man Gimp werden auch nicht Beagle, Tracker oder Zeitgeist als Abhängigkeiten installiert. Würde gerne ein paar KDE-Applikationen einsetzen!
Von ------------------------------ am Fr, 22. April 2016 um 16:17 #
Okular ist immer noch SC4, das zieht über kdelibs strigi.
Phonon-qt4 benötigt libqtzeitgeist (weiß gott warum, ich weiß es nicht) aber nicht zeitgeist (also den trackenden daemon) Phonon-Qt5 hat nur eine build abhängigkeit (und auch da hab' ich keinen Schimmer was das soll - Zeitgeist ist Gnome Geraffel. Evtl. über gstreamer?)
Stimmt, ist Qt4 und ich hab's voll übersehen. Freue mich darauf die Qt5-KDE-Applikationen verwenden zu können. Die sehen wirklich sehr gut aus! Vielen Dank der Erläuterung.
Von Shalok Shalom am So, 24. April 2016 um 03:48 #
Arch KDE kann einfach nicht packen, auch wenn sie noch so viel von demm stehlen: Okular ist hier seit Ewigkeiten auf 5 und funktioniert, wie alles andere, ohne strigi und Zeitgeist. Das einzige Packet, welches hier von default installiert und von strigi abhängig ist, is kdelibs, also die alte Bibliothek und die is default nur für breeze4 da.
Von kamome umidori am Fr, 22. April 2016 um 20:57 #
Kann jemand die Sicherheit des hier verwendeten QtWebKit beurteilen? Ich hoffe, es wird gepflegt, denn von WebKit (oder QtWebKit?) habe ich jetzt auch schon des Öfteren Schlechtes bzgl. der Sicherheit gelesen. Und das hier sieht wirklich nicht gut/aktuell aus: https://trac.webkit.org/wiki/QtWebKitSecurity (erster Treffer für "qtwebkit security")
Von ------------------------------ am Sa, 23. April 2016 um 00:23 #
Webkit selbst wird von Apple, Steam und anderen verwendet, bugs haben die alle mal, nur daß Google in direkter Konkurrenz zu Apple steht und daher mal WebKit geforked hat (als "Blink") - neben der Geschäftspolitik laufen die Grenzen da woanders (der Vorteil von WebKit2/Blink ist die Möglichkeit der prozessualen Abschottung der Browsertabs)
Die toolkit "Derivate" kranken allesamt an dem merge-verfahren. Alle Nase lang wird mal die aktuellste Version von WebKit bzw. Blink (QWebEngine löst *dieses* Problem nicht im Mindesten) eingepflegt, bzw. im Falle von QtWebKit jetzt eben nicht mehr (daher der Verfall) und dann nochmal später released.
Mein guter Rat wäre es, für Browser auf sowas Komplett zu verzichten: die Dinger sind Psuedobetreibssysteme und Vollzeitjob, dh. wenn man Blink oder Webkit (oder Gecko) verwenden will sollte man das tun; direkt! Andernfalls läuft der Browser immer Potentiell auf einer veralteten Engine (so hat man das wenigstens unter Kontrolle)
Für unkritische Sachen mit verläßlichen Inhalt (betrifft KDEPIM, vllt. mit Abstrichen bei html Mails, aber der ECMA Interpreter hat bei Push-Content ohnehin *zwingend* deaktiviert zu sein) ist das aber eher egal. Angrffe würden da ganz klassisch über Stack/Heap-overflows laufen und da sind libjpeg oder libpng kritischer und der Speicherschutz im kernel wichtiger (um die Ausnutzung zu verhindern)
> https://trac.webkit.org/wiki/QtWebKitSecurity
Was willst Du da rauslesen? Das ist ein antiquiertes "wie das hier läuft" wiki - sagt erstmal mehr über googles Index als über irgendwas anderes
Problematisch ist, daß QtWebkit aus 5.6 geflogen ist, dh. das aktuellste webkit ist Oktober 2015 in 5.5.1 gewesen (nicht, daß das das webkit *von* Oktober 2015 gewesen wäre) - danach bist Du auf den Downstream (Deine Distro) angewiesen.
Ggw. bestehen Versuche qtwebkit wiederzubeleben, kA. ob das was wird.
QtWebKit wird NICHT mehr gepflegt und wurde durch QtWebEngine (Chromium-basiert) ersetzt.
Das was Du in Sachen Sicherheit über Webkit gehört hast, waren keine Sicherheitsmängel an WebKit selbst, sondern das Problem, dass viele Programme immer noch QtWebKit oder veraltete WebKitGTK-Versionen verwenden und dass LTS-Distros (Ubuntu, Debian Sta(b)le) Sicherheitsaktualisierungen (u. a. da es keine "reinen Sicherheitsupdates sind) nicht einpflegen.
WebKit ist nur unter Arch- oder Fedora-basierten Distributionen so sicher, wie der WebKit-Upstream die Sicherheit pflegt.
Von Shalok Shalom am So, 24. April 2016 um 03:52 #
QtWebKit wird seit vielen Jahren nicht mehr gepflegt. Wieso die meisten Distros immer noch darauf setzen, ist mir ein Rätsel, KaOS verwendet schon seit Wochen 2.0 mit QtWebEngine und funktioniert sehr gut für mich.
Von Shalok Shalom am So, 24. April 2016 um 04:06 #
Und, weil das ja die eigentliche Frage ist: Akregator ist dort auch schon mit QtWebEngine gebaut. Obwohl das KDE Team selbst in seiner Ankündigung meint, die Arbeiten dafür seien "schon gestartet". Genauso wie Telepathy hier schon QtWebEngine erfolgreich verwendet, während das KDE Team mit ihren anderen Distros noch hinterherhängen. ^-^
2) KaOS funktioniert installiert einwandfrei, das ist der Punkt. QtWebEngine wird in KaOS von einem Paket verwendet: pyqt-python2 Alles andere, was vorher darauf lief, läuft jetzt stabil mit der QtWebEngine.
KDE selbst sieht, weil sie auf ihren Kubuntus, Fedoras und so weiter distrospezifische Fehler finden, Akregator erst am Anfang seiner Portierung und in KaOS funktioniert es. ^^
Das feinste: KDE Telepathy ist hier ebenfalls schon umgestellt, das schaffen sie noch nicht einmal zu bauen.
Von .-,-,-.,-.,-.,-.,-.,-., am So, 24. April 2016 um 15:23 #
Das geht schon "ewig", sprich jahrelang, so.
Z.B. Debian Squeeze wurde ja am 06.02.2011 veröffentlicht.
Ich zitiere deshalb folgendes Kapitel aus den damaligen Release Notes, damit Dir klar wird, wie lange diese Sachverhalte schon bekannt sind (u.a. allen Distros und natürlich auch dem KDE-Projekt):
Debian 6.0 enthält mehrere Browser-Engines, die einem ständigen Ansturm von Sicherheitsproblemen ausgesetzt sind. Die hohe Rate von Anfälligkeiten und die teilweise fehlende Unterstützung seitens der Originalautoren in Form von langfristig gepflegten Programmversionen machen es sehr schwierig, für diese Browser Sicherheitsunterstützung auf Basis von rückportierten Fehlerkorrekturen anzubieten. Zusätzlich machen es Abhängigkeiten zwischen beteiligten Bibliotheken unmöglich, auf neuere Upstream-(Orignal-)Versionen hochzurüsten. Browser, die auf den Engines „qtwebkit“ und „khtml“ aufbauen, sind daher in Squeeze zwar enthalten, es besteht jedoch für sie keine vollständige Sicherheitsunterstützung. Wir werden Anstrengungen unternehmen, um Korrekturen für Sicherheitsprobleme zu finden und zurückzuportieren, aber grundsätzlich sollten diese Browser nicht für Verbindungen zu nicht vertrauenswürdigen Websites verwendet werden.
Für die gewöhnliche Verwendung empfehlen wir Browser, die auf der Mozilla xulrunner-Engine aufbauen (Iceweasel und Iceape), Browser basierend auf der Webkit-Engine (z.B. Epiphany) oder Chromium. Die Historie von xulrunner während der vergangenen Debian-Veröffentlichungszyklen hat eine gute Rückportierbarkeit für ältere Versionen gezeigt.
Chromium ist – obwohl es auf der Codebasis von Webkit aufbaut – ein mehrschichtiges Paket: wenn ein Rückportieren nicht mehr realisierbar ist, gibt es immer noch die Möglichkeit, auf eine aktuellere Originalversion hochzurüsten (was für die webkit-Bibliothek selbst nicht zutrifft).
Webkit wird von den Originalautoren mit einer langfristig gepflegten Programmversion unterstützt."
Der Kernsatz lautet also: "Browser, die auf den Engines „qtwebkit“ und „khtml“ aufbauen, sind daher in Squeeze zwar enthalten, es besteht jedoch für sie keine vollständige Sicherheitsunterstützung."
Das hat sich in Wheezy nicht geändert und auch nicht in Jessie. Zum allgmeinen Webbrowsen sind diese Engines und damit alle Browser, die darauf aufbauen oder bisher darauf aufgebaut haben, also z.B. auch die ältere Qupzillaversion in Debian Jessie Stable, die ja noch Qt4Webkit benutzt, viel zu unsicher. Das gilt ganz genauso für OpenSuse, Ubuntu, Mint und die meisten anderen Distributionen, insofern die betreffenden Browser-Engines noch eingesetzt werden.
Von .-,-.,-.,-.,-.,.-,-.,.- am So, 24. April 2016 um 16:24 #
Kleiner Anhang von mir: Wie ich gerade selbst sehe, baut Qupzilla im nagelneuen Ubuntu 16.04 immer noch auf der alten QtWebkit-Engine auf und ist damit nicht zur allgemeinen Internetbenutzung zu empfehlen.
Diese Empfehlung muss man sogar für Ubuntu selbst aussprechen und zwar dann, wenn man massenweise Universe- und Multiverse-Pakete einsetzt und dann immer noch glaubt, man würde einen durchgehenden 5 Jahre-Ubuntu-LTS-Support genießen. Letztlich heißt das, dass man nur dann fünf Jahre verlässlichen Ubuntu-LTS-Sicherheitssupport genießt, wenn man ausschließlich Unity (oder Twm, das sich als einzige "Desktopalternative" in Ubuntu Main befindet) auf dem Desktop benutzt.
Lern- und Übungssoftware oder Musik-Software?
Ist ein Lernprogramm:
https://www.youtube.com/embed/IxmyevpFErU
Wenn ich in Arch-Linux beispielsweise "Okular" installieren möchte, würde "Strigi" und "Zeitgeist" als Abhängigkeit installiert werden. Ich möchte diese Tracker aber nicht einsetzen. Warum benötigt ein Dokumentenbetrachter unbedingt einen Meta-Tracker? Ein Meta-Tracker sollte doch eher optional integriert sein.
Sollten die KDE-Applications nicht vom KDE-Desktop Plasma unabhängig sein? Die Trennung erscheint mir nicht konsequent und granular. Oder liegt das an einer groben, pauschalen Packetierung der Distribution?
Installiert man Gimp werden auch nicht Beagle, Tracker oder Zeitgeist als Abhängigkeiten installiert.
Würde gerne ein paar KDE-Applikationen einsetzen!
Okular ist immer noch SC4, das zieht über kdelibs strigi.
Phonon-qt4 benötigt libqtzeitgeist (weiß gott warum, ich weiß es nicht) aber nicht zeitgeist (also den trackenden daemon)
Phonon-Qt5 hat nur eine build abhängigkeit (und auch da hab' ich keinen Schimmer was das soll - Zeitgeist ist Gnome Geraffel. Evtl. über gstreamer?)
Stimmt, ist Qt4 und ich hab's voll übersehen.
Freue mich darauf die Qt5-KDE-Applikationen verwenden zu können. Die sehen wirklich sehr gut aus!
Vielen Dank der Erläuterung.
Arch KDE kann einfach nicht packen, auch wenn sie noch so viel von demm stehlen:
Okular ist hier seit Ewigkeiten auf 5 und funktioniert, wie alles andere, ohne strigi und Zeitgeist. Das einzige Packet, welches hier von default installiert und von strigi abhängig ist, is kdelibs, also die alte Bibliothek und die is default nur für breeze4 da.
Kann jemand die Sicherheit des hier verwendeten QtWebKit beurteilen? Ich hoffe, es wird gepflegt, denn von WebKit (oder QtWebKit?) habe ich jetzt auch schon des Öfteren Schlechtes bzgl. der Sicherheit gelesen. Und das hier sieht wirklich nicht gut/aktuell aus:
https://trac.webkit.org/wiki/QtWebKitSecurity
(erster Treffer für "qtwebkit security")
Webkit selbst wird von Apple, Steam und anderen verwendet, bugs haben die alle mal, nur daß Google in direkter Konkurrenz zu Apple steht und daher mal WebKit geforked hat (als "Blink") - neben der Geschäftspolitik laufen die Grenzen da woanders (der Vorteil von WebKit2/Blink ist die Möglichkeit der prozessualen Abschottung der Browsertabs)
Die toolkit "Derivate" kranken allesamt an dem merge-verfahren.
Alle Nase lang wird mal die aktuellste Version von WebKit bzw. Blink (QWebEngine löst *dieses* Problem nicht im Mindesten) eingepflegt, bzw. im Falle von QtWebKit jetzt eben nicht mehr (daher der Verfall) und dann nochmal später released.
Mein guter Rat wäre es, für Browser auf sowas Komplett zu verzichten: die Dinger sind Psuedobetreibssysteme und Vollzeitjob, dh. wenn man Blink oder Webkit (oder Gecko) verwenden will sollte man das tun; direkt!
Andernfalls läuft der Browser immer Potentiell auf einer veralteten Engine (so hat man das wenigstens unter Kontrolle)
Für unkritische Sachen mit verläßlichen Inhalt (betrifft KDEPIM, vllt. mit Abstrichen bei html Mails, aber der ECMA Interpreter hat bei Push-Content ohnehin *zwingend* deaktiviert zu sein) ist das aber eher egal.
Angrffe würden da ganz klassisch über Stack/Heap-overflows laufen und da sind libjpeg oder libpng kritischer und der Speicherschutz im kernel wichtiger (um die Ausnutzung zu verhindern)
> https://trac.webkit.org/wiki/QtWebKitSecurity
Was willst Du da rauslesen? Das ist ein antiquiertes "wie das hier läuft" wiki - sagt erstmal mehr über googles Index als über irgendwas anderes
Problematisch ist, daß QtWebkit aus 5.6 geflogen ist, dh. das aktuellste webkit ist Oktober 2015 in 5.5.1 gewesen (nicht, daß das das webkit *von* Oktober 2015 gewesen wäre) - danach bist Du auf den Downstream (Deine Distro) angewiesen.
Ggw. bestehen Versuche qtwebkit wiederzubeleben, kA. ob das was wird.
QtWebKit wird NICHT mehr gepflegt und wurde durch QtWebEngine (Chromium-basiert) ersetzt.
Das was Du in Sachen Sicherheit über Webkit gehört hast, waren keine Sicherheitsmängel an WebKit selbst, sondern das Problem, dass viele Programme immer noch QtWebKit oder veraltete WebKitGTK-Versionen verwenden und dass LTS-Distros (Ubuntu, Debian Sta(b)le) Sicherheitsaktualisierungen (u. a. da es keine "reinen Sicherheitsupdates sind) nicht einpflegen.
WebKit ist nur unter Arch- oder Fedora-basierten Distributionen so sicher, wie der WebKit-Upstream die Sicherheit pflegt.
Danke Euch!
QtWebKit wird seit vielen Jahren nicht mehr gepflegt.
Wieso die meisten Distros immer noch darauf setzen, ist mir ein Rätsel, KaOS verwendet schon seit Wochen 2.0 mit QtWebEngine und funktioniert sehr gut für mich.
Und, weil das ja die eigentliche Frage ist: Akregator ist dort auch schon mit QtWebEngine gebaut. Obwohl das KDE Team selbst in seiner Ankündigung meint, die Arbeiten dafür seien "schon gestartet". Genauso wie Telepathy hier schon QtWebEngine erfolgreich verwendet, während das KDE Team mit ihren anderen Distros noch hinterherhängen. ^-^
a) "Monaten"
b) KaOS bezieht schlicht div. Anwendungen aus dem playground.
1) https://github.com/qtproject/qtwebkit/graphs/code-frequency
2) KaOS funktioniert installiert einwandfrei, das ist der Punkt.
QtWebEngine wird in KaOS von einem Paket verwendet: pyqt-python2
Alles andere, was vorher darauf lief, läuft jetzt stabil mit der QtWebEngine.
KDE selbst sieht, weil sie auf ihren Kubuntus, Fedoras und so weiter distrospezifische Fehler finden, Akregator erst am Anfang seiner Portierung und in KaOS funktioniert es. ^^
Das feinste: KDE Telepathy ist hier ebenfalls schon umgestellt, das schaffen sie noch nicht einmal zu bauen.
https://gist.github.com/anonymous/d11172f37f8042bdedd67400f2a55345
http://funkyimg.com/i/2b7X6.png
Das geht schon "ewig", sprich jahrelang, so.
Z.B. Debian Squeeze wurde ja am 06.02.2011 veröffentlicht.
Ich zitiere deshalb folgendes Kapitel aus den damaligen Release Notes, damit Dir klar wird, wie lange diese Sachverhalte schon bekannt sind (u.a. allen Distros und natürlich auch dem KDE-Projekt):
https://www.debian.org/releases/squeeze/i386/release-notes/
ch-information.de.html#browser-security
"5.4. Sicherheitsstatus von Webbrowsern
Debian 6.0 enthält mehrere Browser-Engines, die einem ständigen Ansturm von Sicherheitsproblemen ausgesetzt sind. Die hohe Rate von Anfälligkeiten und die teilweise fehlende Unterstützung seitens der Originalautoren in Form von langfristig gepflegten Programmversionen machen es sehr schwierig, für diese Browser Sicherheitsunterstützung auf Basis von rückportierten Fehlerkorrekturen anzubieten. Zusätzlich machen es Abhängigkeiten zwischen beteiligten Bibliotheken unmöglich, auf neuere Upstream-(Orignal-)Versionen hochzurüsten. Browser, die auf den Engines „qtwebkit“ und „khtml“ aufbauen, sind daher in Squeeze zwar enthalten, es besteht jedoch für sie keine vollständige Sicherheitsunterstützung. Wir werden Anstrengungen unternehmen, um Korrekturen für Sicherheitsprobleme zu finden und zurückzuportieren, aber grundsätzlich sollten diese Browser nicht für Verbindungen zu nicht vertrauenswürdigen Websites verwendet werden.
Für die gewöhnliche Verwendung empfehlen wir Browser, die auf der Mozilla xulrunner-Engine aufbauen (Iceweasel und Iceape), Browser basierend auf der Webkit-Engine (z.B. Epiphany) oder Chromium. Die Historie von xulrunner während der vergangenen Debian-Veröffentlichungszyklen hat eine gute Rückportierbarkeit für ältere Versionen gezeigt.
Chromium ist – obwohl es auf der Codebasis von Webkit aufbaut – ein mehrschichtiges Paket: wenn ein Rückportieren nicht mehr realisierbar ist, gibt es immer noch die Möglichkeit, auf eine aktuellere Originalversion hochzurüsten (was für die webkit-Bibliothek selbst nicht zutrifft).
Webkit wird von den Originalautoren mit einer langfristig gepflegten Programmversion unterstützt."
Der Kernsatz lautet also:
"Browser, die auf den Engines „qtwebkit“ und „khtml“ aufbauen, sind daher in Squeeze zwar enthalten, es besteht jedoch für sie keine vollständige Sicherheitsunterstützung."
Das hat sich in Wheezy nicht geändert und auch nicht in Jessie. Zum allgmeinen Webbrowsen sind diese Engines und damit alle Browser, die darauf aufbauen oder bisher darauf aufgebaut haben, also z.B. auch die ältere Qupzillaversion in Debian Jessie Stable, die ja noch Qt4Webkit benutzt, viel zu unsicher. Das gilt ganz genauso für OpenSuse, Ubuntu, Mint und die meisten anderen Distributionen, insofern die betreffenden Browser-Engines noch eingesetzt werden.
Kleiner Anhang von mir:
Wie ich gerade selbst sehe, baut Qupzilla im nagelneuen Ubuntu 16.04 immer noch auf der alten QtWebkit-Engine auf und ist damit nicht zur allgemeinen Internetbenutzung zu empfehlen.
Diese Empfehlung muss man sogar für Ubuntu selbst aussprechen und zwar dann, wenn man massenweise Universe- und Multiverse-Pakete einsetzt und dann immer noch glaubt, man würde einen durchgehenden 5 Jahre-Ubuntu-LTS-Support genießen. Letztlich heißt das, dass man nur dann fünf Jahre verlässlichen Ubuntu-LTS-Sicherheitssupport genießt, wenn man ausschließlich Unity (oder Twm, das sich als einzige "Desktopalternative" in Ubuntu Main befindet) auf dem Desktop benutzt.
Siehe auch:
http://www.heise.de/open/meldung/Ubuntu-LTS-
Lauter-Sicherheitsluecken-trotz-Langzeitpflege-3181830.html
Vollkommen korrekt.