Login
Newsletter
Werbung

Thema: Ubuntu 16.04.6 LTS freigegeben

12 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Ghul am Fr, 1. März 2019 um 13:13 #

in universe und multiverse.

Leider werden Pakete in diesen Repositorys von Canonical auch nicht supported.

Selbst in 18.04 hat sich schon einiges an Sicherheitslücken angesammelt. Die letzten regulären Updates für universe und multiverse erhielt es im März/April 2018, also vor knapp 11-12 Monaten.

  • 0
    Von nurso am Fr, 1. März 2019 um 22:28 #

    Man darf unter diesen Umständen halt keine Server-Software aus Universe benutzen, es sei denn, man wartet diese selbst oder man weiß definitiv, dass diese 100%ig supportet wird. Webbrowser in Universe ohne jedes Update wie etwa Qupzilla oder Midori sollten tunlichst nur ohne Javascript eingesetzt werden oder man wechselt gleich auf den in Main befindlichen Firefox. Ansonsten sollte das Risiko überschaubar bleiben.

    Wenn allerdings die wirklich sehr breit genutzten Gstreamer-ffmpeg/-libav, -bad und -ugly-Pakete von schweren Sicherheitslücken betroffen sein sollten (was in der Vergangenheit schon einmal vorkam), dann wird es schnell wirklich kritisch.

    Die beste Strategie für Ubuntu-Nutzer, die viel Universe- und Multiverse-Software benutzen, dürfte wohl sein, jedes LTS-Release nur zwei Jahre zu benutzen, und zwar solange, bis das nächste erschienen ist. Dann sollte man direkt upgraden, also quasi immer im Zwei-Jahres-Rhythmus.

    Der Fünf-Jahre-LTS ist nur für reine Ubuntu Main-Nutzer sinnvoll.

    • 0
      Von Ghul am Fr, 1. März 2019 um 23:38 #

      Man darf unter diesen Umständen halt keine Server-Software aus Universe benutzen, es sei denn, man wartet diese selbst oder man weiß definitiv, dass diese 100%ig supportet wird.

      Damit ist es nicht getan.
      Man darf auch jede Menge Client Software nicht mehr einsetzen.

      Das wären bspw. Torrent Clients, IRC Clients, Instant Messanger, FTP Software, sowie sicherlich auch das ein oder andere Spiel.

      Die beste Strategie für Ubuntu-Nutzer, die viel Universe- und Multiverse-Software benutzen, dürfte wohl sein, jedes LTS-Release nur zwei Jahre zu benutzen, und zwar solange, bis das nächste erschienen ist. Dann sollte man direkt upgraden, also quasi immer im Zwei-Jahres-Rhythmus.

      Naja, das löst das Problemnicht wirklich. Eine LTS kann ja schließlich schon in ihren ersten 2 Jahren Sicherheitslücken enthalten, die nicht gefixt werden.
      Bestenfalls ist nur die Community bei der neueren LTS Version etwas größer und ein paar alte Sicherheitslücken gefixt, aber die neuen werden trotzdem vorhanden sein und dann kommt es darauf an, wie schwerwiegend die sind.

      • 0
        Von JohannesP am Sa, 2. März 2019 um 10:13 #

        Was also stattdessen nutzen?

        • 0
          Von Ghul am Sa, 2. März 2019 um 10:57 #

          Debian Stable.

          Da haben alle Pakete im Repository einen offiziellen Maintainer, der für das Paket zuständig und verantwortlich ist.
          Grundsätzlich gilt der Support für alle Pakete im Repository, es werden theoretisch also alle supported.
          Sollte das mal nicht passieren, weil der Maintainer z.B. seine Arbeit nicht macht oder ein Paket nicht repariert werden kann, dann kann man das zumindest im Debian Package Tracker einsehen und sich somit darauf einstellen.
          Man weiß also zu jeder Zeit, welches Paket eine bekannte Sicherheitslücke hat, die noch nicht in Debian gefixt wurde.
          Für Pakete, bei denen der Support zu wünschen übrig lässt, wird ein neuer Maintainer gesucht und der alte ersetzt oder das Paket entfernt. Letzteres gleiche gilt für Pakete, die nicht reparierbar sind.

          Insofern hat man hier in jeder Hinsicht eine wesentlich bessere Grundlage als bei Ubuntu.

          Bei Ubuntu ist für die universe und multiverse Pakete keiner zuständig und es gibt auch keinen Paket Tracker, außer vielleicht den allgemeinen Bugtracker, wo man nachsehen könnte, welche jetzt Sicherheitslücken enthalten oder nicht.
          Der Bugtracker von Ubuntu hat aber das Problem, das da erstens alles mögliche eingetragen wird und zweitens halt nur die Sicherheitslücken als Eintrag drin stehen, die irgendwer mal gemeldet hat. Aktiv getracked auch unter Verwendung von CVE Meldungen, wie bei Debian, werden die Pakete da nicht.

          0
          Von #! am Sa, 2. März 2019 um 11:00 #

          Die halbjährlich erscheinenden STS-Releases oder eine andere Distro.
          Das Problem betrifft übrigens auch andere Distributionen mit eingefrorenen Paketquellen wie Debian. Auch wenn alle Pakete Sicherheitsaktualisierungen erhalten und die Maintainer schnell alles einpflegen, so lassen sich längst nicht alle upstream gefixten Sicherheitslücken in reine Sicherheitsupdates zurückportieren.

          • 0
            Von Tamaskan am Sa, 2. März 2019 um 15:35 #

            Aus diesem Grund ist die Anzahl der in RHEL/CentOS oder SLE verfügbaren Pakete auch sehr viel kleiner als bei Debian oder Fedora, weil Red Hat bzw. SUSE den Support nicht für jedes noch so exotische Paket garantieren kann. Außerdem gibt es "Minor Releases" bzw. "Service Packs", die dann doch einige Pakete auf eine neue Upstream-Version aktualisieren. Sonst wäre der Aufwand gar nicht zu stemmen.

            Es gibt zusätzliche Repositories wie EPEL, RPMFusion und ELRepo, die aber von der Community gepflegt werden, bei SLE gibt es den PackageHub, der Pakete aus openSUSE enthält. Die Pakete in offiziell unterstützt und nicht unterstützt aufzuteilen ist also nichts neues für "LTS-Distros". Der Unterschied: bei Ubuntu sind alle Repos standardmäßig aktiviert und man weiß u.u. gar nicht, das man ein nicht unterstütztes Paket installiert, wenn man das nicht explizit überprüft.

            Debian unterstützt theoretisch das ganze Repository, und für jedes Paket gibt es einen Maintainer. Es kann aber sein, dass während der Laufzeit einer Debian-Version einzelne Pakete aus dem Repository plötzlich entfernt (!) werden können, wenn der Maintainer den Support nicht leistet, oder das Paket wird mit einer Markierung versehen, wenn andere Pakete davon abhängen (apt install debian-security-support, dann check-support-status aufrufen). Das kann aber auch dauern, bis das jemand bemerkt.

            • 0
              Von Ghul am Sa, 2. März 2019 um 15:47 #

              us diesem Grund ist die Anzahl der in RHEL/CentOS oder SLE verfügbaren Pakete auch sehr viel kleiner als bei Debian oder Fedora, weil Red Hat bzw. SUSE den Support nicht für jedes noch so exotische Paket garantieren kann.

              Das liegt einfach daran, weil diese Distris jeweils von einem privatwirtschaftlich agierenden Unternehmen betrieben werden und somit die Unternehmen in der Gewinnzone bleiben müssen.

              Bei Debian ist das nicht so, da sind es Freizeitentwickler. Debian benötigt somit nur mehr davon.
              Daraus folgt dann auch, Debian wird umso besser, je mehr Nutzer es hat.
              Denn es wird immer mal den ein oder anderen Nutzer geben, der später dann zum Debianmaintainer wird.

              Es wäre also im Interesse aller Debianer, dass die Distribution durch bspw. eine bessere Usability Marktanteile gewinnt. Aber das scheinen leider noch nicht alle Debianer verstanden zu haben, weswegen es in den letzten Jahren Marktanteile an Ubuntu & Co abgegeben hat.

              • 0
                Von Tamaskan am Sa, 2. März 2019 um 16:02 #

                Da rennst du bei mir offene Türen ein. Thema proprietäre Firmware, warum nicht das non-free-ISO zum Standard machen (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/)? Wenn man keine Hardware hat, die proprietäre Firmware benötigt, wird diese sowieso nicht installiert, und wenn doch, dann muss man diese sowieso installieren um vernünftig arbeiten zu können. Wer trotzdem keine proprietäre Firmware will, benutzt halt weiterhin das free-ISO.

                Nächster Punkt: Paketbau. DEB-(und auch RPM-)Pakete zu bauen ist unnötig kompliziert. Arch Linux macht vor, wie es richtig geht, mit makepkg und den PKGBUILD-Dateien - anhand des umfangreichen Angebots der AURs sieht man, dass die User damit zurecht kommen, man muss sich schon anstrengen, um eine Software zu finden, die *nicht* im AUR ist. Und wenn man etwas mehr Erfahrung hat und sich mehr einbringen will ist es leicht zum Trusted User oder Developer aufzusteigen.

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung