Die schauen halt genauso oft in alten KDE-/Qt-Code hinein wie Ihr.
Und darunter sind weiß Gott schon sehr, sehr viele KDE4- und Qt-Versionen. Eure Software ist dabei so herrlich wartbar und Euer Sicherheitssupport so langelebig und umfassend, dass selbst Debian die Sicherheit seiner verwendeten QtWebkit- und Khtml-Webbrowserengines in einer noch gar nicht so alten KDE4-/Qt4-Version nicht garantieren kann.
" Debian 7.0 includes several browser engines which are affected by a steady stream of security vulnerabilities. The high rate of vulnerabilities and partial lack of upstream support in the form of long term branches make it very difficult to support these browsers with backported security fixes. Additionally, library interdependencies make it impossible to update to newer upstream releases. Therefore, browsers built upon the webkit, qtwebkit and khtml engines are included in Wheezy, but not covered by security support. These browsers should not be used against untrusted websites.
For general web browser use we recommend browsers building on the Mozilla xulrunner engine (Iceweasel and Iceape) or Chromium.
Xulrunner has had a history of good backportability for older releases over the previous release cycles. Chromium - while built upon the Webkit codebase - is a leaf package, which will be kept up-to-date by rebuilding the current Chromium releases for stable. "
Nenne bitte Sicherheitslücken, die KDE3 und Qt3 betreffen, beim Namen. Vielleicht bekommst Du auch ein Dankeschön, wenn Du das direkt in der Red Hat Bugzilla mindest, schließlich ist KDE 3.5.4 noch immer in RHEL5 enthalten.
Auf lwn.net hast Du kurioserweise eine Sicherheitslücke in Qt 4.3 benannt. Das ist Euer alter, ungefixter Code, der auch ungefixt bleiben wird.
Das liegt aber an Dir, da Du diese gar nicht beschrieben hast. Auf Links verweisen kann jeder. Zudem schreibst Du immer "obviously", hundertprozentig sicher bist Du Dir dabei also nicht.
Die Lücke, die Du beschreibst, stammt von März 2011: http://blog.qt.digia.com/blog/2011/03/29/security-advisory-fraudulent-certificates/
Deiner Theorie nach sollte diese auch in irgendeiner Form in KDE 3 enthalten sein. Nun supportet Red Hat mit KDE 3.5.4 noch ein alte KDE-Version in RHEL5.
Unter den Red Hat Secirity Advisories kann ich die von Dir erwähnte Lücke nicht finden, unter Umständen habe ich diese aufgrund der Unzahl von Fixes übersehen, aber offensichtlich hat Red Hat nicht entsprechend gepatcht: https://rhn.redhat.com/errata/rhel-client-workstation-errata.html
IMO solltest Du deshalb diese Lücke als Bugreport an Red Hat senden, insofern diese wirklich relevant sein sollte. Im Gegensatz zu mir bist Du ja ein aktueller KDE-Entwickler und weißt über KDE Bescheid. Das würde auch Deiner lwn.net-Äußerung Gewicht verleihen.
Das ist natürlich Arbeit, aber Du hast den Stein ja unbedingt ins Rollen bringen müssen.
Und: Auf die Khtml-Kritik, die ich über das Debian-Zitat zum Ausdruck bringen wollte, bist Du gar nicht eingegangen.
Wie schätzt Du denn den Sicherheitsstatus der Khtml-Engine in KDE4-Konqueror ein? Kannst Du guten Gewissens diesen Webbrowser fürs Online-Banking empfehlen?
Mein beruflicher Bereich ist dabei übrigens ein völlig anderer, von daher trifft mich Deine Kritik nicht wirklich, da ich im Bereich Betriebssysteme speziell und Informatik im allgemeinen ein blutiger Laie bin. Ich bin letztlich nur deshalb überhaupt komplett zu Linux gewechselt, weil ich die WindowsXP-Aktivierung nicht akzeptieren konnte und damals gewissermaßen auf Win98 fest saß.
Von mgraesslin am So, 21. Dezember 2014 um 11:21 #
ich habe keine Ahnung ob und wie Red Hat KDE 3.5 supported und ob die von mir in LWN aufgezeigte Schwachstelle unter Red Hat gültig ist oder nicht, behoben ist oder nicht. Das ist mir auch ganz ehrlich ziemlich egal, daher werde ich es auch nicht an Red Hat in den Bugtracker senden.
Auf deine Kritik an KHTML bin ich nicht eingegangen, da das ein Strawman Argument ist, dass du da aufbringst. Ob Debian KHTML nicht maintained oder doch ist ziemlich egal für die Frage zu KHTML in Trinity.
Die vertreiben vll. auch eine unsichere Version dieser Software, demnach sollte es dir nicht egal sein, oder verstehe ich deine Motivation nicht mehr?
Hat openSuSE, oder RH denn genug Manpower um deren angebotenes KDE 3.5 weiter zu versorgen? Ich hoffe Debian schafft es trotz dem Mangel an KDE 4 Maintainern deren KDE 4 Pakete mit wichtigen Patches zu versorgen. Wieso lässt du diese Projekte außen vor und warnst nicht auch davor?
Vermutlich, weil openSUSEs KDE3 und Red Hats KDE3 in RHEL5 sich möglichst nahe am KDE3-Original halten und sich nur um ein paar wenige Fehlerbehebungen und Sicherheitsupdates kümmern. Die Entwicklerzahl reicht für mehr nicht aus und eine separate Weiterentwicklung ist zudem nicht beabsichtigt.
Ein openSUSE-Maintainer hatte das schon im Jahre 2011 unter http://lists.opensuse.org/opensuse-kde3/2011-12/msg00028.html auf den Punkt gebracht:
[Die damalige Frage an den betreffenden openSUSE-Maintainer:]
"Can anyone tell me if it is expected that the OpenSuse KDE3 repos will be updated with material from the Trinity project?"
[Dazu die Antwort:]
I don't think so.
First I think Trinity is not stable enough currently. Also Trinity has many non-desired changes, for example, some Ubuntu-specific patches (even including Ubuntu artwork and calls to dpkg somewhere). These patches should be removed from Trinity before it could be considered.
Also it includes some changes (particularly, changes to kwin window manager) which are highly objected by the former KDE3 developers as bringing in mess and instability.
Finally it requires a specially patched Qt3 which is not compatible with normal Qt3. As Qt3 is still a part of LSB (Linux Standard Base) standard, it is highly unlikely that openSUSE can include this custom Qt3 variant instead of standard-compatible version (as openSUSE needs be LSB-certified).
Also KDE:KDE3 repository includes much of software (about 500 source packages) which are not included in Trinity and would require full-text source conversion to be built against Trinity libraries (plain building against Trinity would not work).
That said, there is always possibility that any worthful changes from Trinity (or any other project) to be included in KDE:KDE3 repository."
Wenn man durch die 2014er-KDE3-Diskussion auf den openSUSE-Mailinglisten schaut, so hat sich an dieser Einstellung bis heute praktisch nichts geändert.
Von .-,.-,.-,.-,.--..-, am Di, 13. Januar 2015 um 18:01 #
Von wegen Strawman Argument.
Debians offizielle Begründung für das (z.B. über das Tool debian-security-status ersichtlich), was u.a. zu Khtml in den Release Notes regelmäßig geschrieben wird:
"Khtml has no security support upstream, only for use on trusted content."
Die Khtml-Engine verfügt somit offenbar über keinen Upstream-Sicherheitssupport.
Die schauen halt genauso oft in alten KDE-/Qt-Code hinein wie Ihr.
Und darunter sind weiß Gott schon sehr, sehr viele KDE4- und Qt-Versionen. Eure Software ist dabei so herrlich wartbar und Euer Sicherheitssupport so langelebig und umfassend, dass selbst Debian die Sicherheit seiner verwendeten QtWebkit- und Khtml-Webbrowserengines in einer noch gar nicht so alten KDE4-/Qt4-Version nicht garantieren kann.
Siehe
http://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#browser-security
" Debian 7.0 includes several browser engines which are affected by a steady stream of security vulnerabilities. The high rate of vulnerabilities and partial lack of upstream support in the form of long term branches make it very difficult to support these browsers with backported security fixes. Additionally, library interdependencies make it impossible to update to newer upstream releases. Therefore, browsers built upon the webkit, qtwebkit and khtml engines are included in Wheezy, but not covered by security support. These browsers should not be used against untrusted websites.
For general web browser use we recommend browsers building on the Mozilla xulrunner engine (Iceweasel and Iceape) or Chromium.
Xulrunner has had a history of good backportability for older releases over the previous release cycles. Chromium - while built upon the Webkit codebase - is a leaf package, which will be kept up-to-date by rebuilding the current Chromium releases for stable. "
Nenne bitte Sicherheitslücken, die KDE3 und Qt3 betreffen, beim Namen. Vielleicht bekommst Du auch ein Dankeschön, wenn Du das direkt in der Red Hat Bugzilla mindest, schließlich ist KDE 3.5.4 noch immer in RHEL5 enthalten.
Auf lwn.net hast Du kurioserweise eine Sicherheitslücke in Qt 4.3 benannt. Das ist Euer alter, ungefixter Code, der auch ungefixt bleiben wird.
Und damit hast du bewiesen, dass du nicht verstanden hast worum es in der Schwachstelle geht und warum TDE davon betroffen ist.
Das liegt aber an Dir, da Du diese gar nicht beschrieben hast. Auf Links verweisen kann jeder. Zudem schreibst Du immer "obviously", hundertprozentig sicher bist Du Dir dabei also nicht.
Die Lücke, die Du beschreibst, stammt von März 2011:
http://blog.qt.digia.com/blog/2011/03/29/security-advisory-fraudulent-certificates/
Deiner Theorie nach sollte diese auch in irgendeiner Form in KDE 3 enthalten sein. Nun supportet Red Hat mit KDE 3.5.4 noch ein alte KDE-Version in RHEL5.
Unter den Red Hat Secirity Advisories kann ich die von Dir erwähnte Lücke nicht finden, unter Umständen habe ich diese aufgrund der Unzahl von Fixes übersehen, aber offensichtlich hat Red Hat nicht entsprechend gepatcht:
https://rhn.redhat.com/errata/rhel-client-workstation-errata.html
IMO solltest Du deshalb diese Lücke als Bugreport an Red Hat senden, insofern diese wirklich relevant sein sollte. Im Gegensatz zu mir bist Du ja ein aktueller KDE-Entwickler und weißt über KDE Bescheid. Das würde auch Deiner lwn.net-Äußerung Gewicht verleihen.
Das ist natürlich Arbeit, aber Du hast den Stein ja unbedingt ins Rollen bringen müssen.
Und: Auf die Khtml-Kritik, die ich über das Debian-Zitat zum Ausdruck bringen wollte, bist Du gar nicht eingegangen.
Wie schätzt Du denn den Sicherheitsstatus der Khtml-Engine in KDE4-Konqueror ein?
Kannst Du guten Gewissens diesen Webbrowser fürs Online-Banking empfehlen?
Mein beruflicher Bereich ist dabei übrigens ein völlig anderer, von daher trifft mich Deine Kritik nicht wirklich, da ich im Bereich Betriebssysteme speziell und Informatik im allgemeinen ein blutiger Laie bin. Ich bin letztlich nur deshalb überhaupt komplett zu Linux gewechselt, weil ich die WindowsXP-Aktivierung nicht akzeptieren konnte und damals gewissermaßen auf Win98 fest saß.
ich habe keine Ahnung ob und wie Red Hat KDE 3.5 supported und ob die von mir in LWN aufgezeigte Schwachstelle unter Red Hat gültig ist oder nicht, behoben ist oder nicht. Das ist mir auch ganz ehrlich ziemlich egal, daher werde ich es auch nicht an Red Hat in den Bugtracker senden.
Auf deine Kritik an KHTML bin ich nicht eingegangen, da das ein Strawman Argument ist, dass du da aufbringst. Ob Debian KHTML nicht maintained oder doch ist ziemlich egal für die Frage zu KHTML in Trinity.
Die vertreiben vll. auch eine unsichere Version dieser Software, demnach sollte es dir nicht egal sein, oder verstehe ich deine Motivation nicht mehr?
Hat openSuSE, oder RH denn genug Manpower um deren angebotenes KDE 3.5 weiter zu versorgen? Ich hoffe Debian schafft es trotz dem Mangel an KDE 4 Maintainern deren KDE 4 Pakete mit wichtigen Patches zu versorgen. Wieso lässt du diese Projekte außen vor und warnst nicht auch davor?
Vermutlich, weil openSUSEs KDE3 und Red Hats KDE3 in RHEL5 sich möglichst nahe am KDE3-Original halten und sich nur um ein paar wenige Fehlerbehebungen und Sicherheitsupdates kümmern. Die Entwicklerzahl reicht für mehr nicht aus und eine separate Weiterentwicklung ist zudem nicht beabsichtigt.
Ein openSUSE-Maintainer hatte das schon im Jahre 2011 unter
http://lists.opensuse.org/opensuse-kde3/2011-12/msg00028.html
auf den Punkt gebracht:
[Die damalige Frage an den betreffenden openSUSE-Maintainer:]
"Can anyone tell me if it is expected that the OpenSuse KDE3 repos will be updated with material from the Trinity project?"
[Dazu die Antwort:]
I don't think so.
First I think Trinity is not stable enough currently. Also Trinity has many
non-desired changes, for example, some Ubuntu-specific patches
(even including Ubuntu artwork and calls to dpkg somewhere). These
patches should be removed from Trinity before it could be considered.
Also it includes some changes (particularly, changes to kwin window manager) which are highly objected by the former KDE3 developers as bringing in mess and instability.
Finally it requires a specially patched Qt3 which is not compatible with normal Qt3. As Qt3 is still a part of LSB (Linux Standard Base) standard, it is highly unlikely that openSUSE can include this custom Qt3 variant instead of standard-compatible version (as openSUSE needs be LSB-certified).
Also KDE:KDE3 repository includes much of software (about 500 source packages) which are not included in Trinity and would require full-text source conversion to be built against Trinity libraries (plain building against Trinity would not work).
That said, there is always possibility that any worthful changes from Trinity
(or any other project) to be included in KDE:KDE3 repository."
Wenn man durch die 2014er-KDE3-Diskussion auf den openSUSE-Mailinglisten schaut, so hat sich an dieser Einstellung bis heute praktisch nichts geändert.
Von wegen Strawman Argument.
Debians offizielle Begründung für das (z.B. über das Tool debian-security-status ersichtlich), was u.a. zu Khtml in den Release Notes regelmäßig geschrieben wird:
"Khtml has no security support upstream, only for use on trusted content."
Die Khtml-Engine verfügt somit offenbar über keinen Upstream-Sicherheitssupport.