Login
Newsletter
Werbung

Thema: Qt 5.12 LTS als Betaversion erhältlich

10 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von klopskind am Mo, 8. Oktober 2018 um 15:59 #

Hier steht (eigene Hervorhebungen)

Qt 5.12 LTS is a long-term supported release. It will be supported for three years, after which you can purchase extended support. As an LTS, it will receive multiple patch-level releases that provide bug fixes, improvements and security fixes.
Wie werden/wurden denn klaffende Sicherheitslücken in den LTS-Veröffentlichungszweigen handgehabt? Und wie wird/wurde das speziell für Qt WebEngine umgesetzt?

Ich konnte dazu bisher keine wirklich belastbaren Aussagen finden:

    • We do update to the latest Chromium version in use before a Qt release. After a release some bug fixes and security patches are backported. For LTS releases of Qt we might also update Chromium in a patch level release.
      Quelle mit eigenen Hervorhebungen

      ..., there have been a bunch of security fixes to the Chromium codebase that users did not get.

      This changes now. Following the example of the Fedora KDE team, we now ship the latest QtWebEngine release regardless of the rest of Qt.

      This means: Leap 15 has Qt 5.9 LTS and QtWebEngine 5.10.1 and will get QtWebEngine 5.11 and further future versions ASAP.

      As an added bonus, we even ship additional security fixes that are not in 5.10.1. This is thanks to the work done in Fedora whose patches we could simply apply without much work on our part.

      Quelle mit eigenen Hervorhebungen
  • Wirklich verbindlich wirkt das jedenfalls nicht. Welche der Sicherheitslücken werden denn nun behoben (und welche nicht)?

    • 0
      Von klopskind am Mo, 8. Oktober 2018 um 16:03 #

      An diesem Punkt möchte ich mich für den aggressiven Unterton meines Kommentars und der darin enthaltenen Fragen entschuldigen. Beim nächsten Kommentar werde ich noch einmal gründlicher drüberlesen :)

      Ich danke jedem Antwortenden im Voraus!

      • 0
        Von Anonymous am Di, 9. Oktober 2018 um 12:00 #

        Hmmm, ich entschuldige mich nicht für meine Pöbeleien ;)

        Die IT betreibt seit 50 Jahren organisierte Verantwortungslosigkeit. Jahr für jahr wird immer mehr unsicherer Mist aufeinander geschichtet, weil alle anderen das auch so machen.

        Und den Nutzern/Kunden sagt man: "Das ist alles sooo kompliziert, dass man es nicht sicher bekommen kann. Friss oder stirb."

        Da bleibt einem nur, möglichst wenig von dem zu fressen, was einem vorgesetzt wird, und zu hoffen, dass die unbedarften Nutzer die Vorkoster bilden, denen das Zeug um die Ohren fliegt, während man selber weit genug weg ist.

        • 0
          Von klopskind am Di, 9. Oktober 2018 um 20:13 #

          Da ist natürlich etwas dran, aber leider bin ich nun immer noch so schlau wie vorher.

          Benutzen Sie keine gängige Browser-Engine? Wie haben Sie Ihren Kommentar verfasst? Mit Lynx, w3m oder netsurf?

          • 0
            Von Anonymous am Di, 9. Oktober 2018 um 21:16 #

            Na ja,

            meist Firefox - hoffentlich das "kleinste Übel". Ich habe mehrere Firefox-Profile eingerichtet, hier auf Pro-Linux funktioniert immer noch das restriktivste ohne Javascript, aber mit uMatrix. Und gehärtet mit GHacks' user.js

            Und Qt5 setze ich nur für 2 oder 3 kleine Anwendungen ein, die keine Netzwerk-Funktionalität aufweisen.

            100% sicher ist halt gar nix in der IT, aber man kann versuchen, die Angriffsfläche möglichst klein zu halten.

    0
    Von Ghul am Di, 9. Oktober 2018 um 19:49 #

    Lediglich der Browser ist damit ausgenommen.

    Was man sich da an Sicherheitslücken in die GUI Anwendung einbaut ist nicht mehr schön, vor allem, wenn das GUI Programm dann z.B. als Flatpak geliefert wird und die Webengine somit so gut wie nie irgendwelche Updates erhält.

    • 0
      Von klopskind am Di, 9. Oktober 2018 um 20:21 #

      Ich bin ebenfalls kein großer Fan von Electron etc., aber denke, dass genau eine sichere, schlanke, wartbare, gewartete im Toolkit integrierte Browser-Engine nicht mehr Vor- als Nachteile bringt.

      Neben dem Browser selbst halte ich Browser-Engines auch in anderen GUI-Programmen für sinnvoll, z.B. in Hilfe-Anwendungen (gut, das ist eine Art abgespeckter "Browser") oder MUAs/Mail-Klienten.

      • 0
        Von klopskind am Di, 9. Oktober 2018 um 20:24 #

        Ich bin ebenfalls kein großer Fan von Electron etc., aber denke, dass genau eine sichere, schlanke, wartbare, gewartete im Toolkit integrierte Browser-Engine nicht mehr Vor- als Nachteile bringt.

        Natürlich meinte ich genau das Gegenteil...

        0
        Von Ghul am Di, 9. Oktober 2018 um 22:06 #

        Für Hilfe Anwendungen würde ein reiner (X)HTML Reader genügen. Dafür braucht man weder Javascript, noch Webabssembly, noch Netzwerkcode oder sonstige Features, die in einem Browser alle eingebaut sind.

        Eine reine Text und Grafikdarstellung, sowie CSS würde da schon genügen.
        XHTML strict würde sich dafür anbieten denn das hält den Parser schlank und einfach.

        Für Hilfezugriffe ins Web sollte eine GUI Anwendung nicht auf eigene Lösungen setzten, sondern eher den installierten und auf dem System zum Standard gesetzten Browser starten und auf dem die Webseite aufrufen, denn dieser Browser wird auch gewartet.

        Von Umfangreichen Webengines halte ich absolut gar nichts. Die im Toolkit integrierte Lösung verbessert zwar die Situation, ist aber doch nur eine Symptombekämpfung. Der Fehler liegt im Design, nämlich, dass man so eine Fullfeatured Webengine erst gar nicht für offline GUI Programme verwendet.

        • 0
          Von klopskind am Mi, 10. Oktober 2018 um 11:11 #

          Für Hilfe Anwendungen würde ein reiner (X)HTML Reader genügen. Dafür braucht man weder Javascript, noch Webabssembly, noch Netzwerkcode oder sonstige Features, die in einem Browser alle eingebaut sind.

          Eine reine Text und Grafikdarstellung, sowie CSS würde da schon genügen.
          XHTML strict würde sich dafür anbieten denn das hält den Parser schlank und einfach.

          Das ist natürlich korrekt. Allerdings können JavaScript & co in den meisten Implementierungen zur Laufzeit deaktiviert werden. Also wieso mehr als eine Browser-Engine je System verwenden, wenn es genau eine schon tut? Zugegeben, diese eine Browser-Engine müsste umfangreicher sein, um alle Anwendungsfälle abdecken zu können.

          Für Hilfezugriffe ins Web sollte eine GUI Anwendung nicht auf eigene Lösungen setzten, sondern eher den installierten und auf dem System zum Standard gesetzten Browser starten und auf dem die Webseite aufrufen, denn dieser Browser wird auch gewartet.
          Dem stimme ich voll und ganz zu. Ich hatte mich jedoch auf lokale Hilfesysteme, die gemeinsam mit einer Anwendung ausgeliefert und verteilt werden, beziehen wollen. Hierfür erscheint es mir in bestimmten Fällen sinnvoller, die Hilfefunktion mittels (genau) einer Browser-Engine-Bibliothek in die jeweilige Software zu integrieren.
          Von Umfangreichen Webengines halte ich absolut gar nichts.
          Ich bin auch für schlankere Browser-Engines. Problem sind hier im Wesentlichen die auftretenden Inkompatibilitäten der einzelnen Implementierung bzw. der Aufwand diese Inkompatibilitäten aufzulösen. Grund ist die (teils ungerechtfertigte und unnötige) Komplexität, welche hier vorallem aus den historische Altlasten wegen der Abwärtskompatibiltäten, den vielen unterschiedlichen Standards und deren Striktheit/Laxheit, z.B. XHTML(strict) vs HTML5 ("Living-Standard") und ggf. der Ignoranz der Webentwickler_innen, oder die der Implementierer_innen der Browser, herrührt.

          Keiner von uns beiden macht die Regeln. Irgendjemand hält es für sinnvoll, umfangreiche Browser-Engines zu entwickeln, obwohl es ein ziemlich aufwändiges Unterfangen ist. Der jeweilige Anwendungszweck begründet die Sinnhaftigkeit.

          Die im Toolkit integrierte Lösung verbessert zwar die Situation, ist aber doch nur eine Symptombekämpfung.
          Immerhin! Zur Lösung von Problemen zählt im Allgemeinen eben nicht nur die Ursachen-, sondern auch die Symptombekämpfung.
          Der Fehler liegt im Design, nämlich, dass man so eine Fullfeatured Webengine erst gar nicht für offline GUI Programme verwendet.
          Wieso ist das ein Fehler? Genau eine im Toolkit/System integrierte, umfangreiche Web-Engine, die alle Anwendungsfälle abdeckt, reicht schon. Funktionalitäten, die für einzelne Anwendungsfälle nicht benötigt werden, wie z.B. JavaScript, können doch schon heute vom Anwendungsentwickler individuell deaktiviert werden.
          Würden Sie stattdessen lieber mehrere Web-Engines parallel verwenden, eine umfangreiche und eine schlanke? Wie viele bräuchte es (zukünftig) dazwischen noch, um alle Anwendungszwecke abzudecken?

    Pro-Linux
    Pro-Linux @Facebook
    Neue Nachrichten
    Werbung