Login
Newsletter
Werbung

Thema: Slackware 14.2 als Veröffentlichungskandidat

2 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Anonymous am Sa, 19. März 2016 um 13:49 #

Das sehe ich nicht als Nachteil.

Slackware ist für Leute, die es schlicht und einfach mögen, so dass sie selbst gut dran basteln können. Und die geringe Personenzahl ist der Garant dafür, dass es so bleibt, denn die paar Leute wollen sich schon aus Selbstschutz nicht "just for Fun" das Leben schwer machen.

Was passiert, wenn jeder mitmacht, sieht man an KDE. Das ist mittlerweile in 3 Subprojekte zerfallen, die Mühe haben, miteinander zu reden, und die Distributionen "dürfen" sich ein funktionierendes Gesamtpaket selbst zusammensuchen.

[
| Versenden | Drucken ]
  • 0
    Von brrrrrr am So, 20. März 2016 um 16:48 #

    Das ist IMO dann ein Nachteil, wenn sich P.V. neue Sicherheitslücken anschaut, dann überprüft, ob Slackware betroffen ist, danach entscheidet, dass es keine Updates geben wird und niemandem mitteilt, warum Sicherheitsupdates nun ausgeblieben sind.

    Das folgende Glibc-Update zeigt stellvertretend, um was es dabei geht:
    http://www.slackware.com/security/viewer.php?l=slackware-security&y=2016&m=slackware-security.569827
    [slackware-security] glibc (SSA:2016-054-02)

    New glibc packages are available for Slackware 14.1 and -current to
    fix security issues.


    Here are the details from the Slackware 14.1 ChangeLog:
    +--------------------------+
    patches/packages/glibc-2.17-i486-11_slack14.1.txz: Rebuilt.
    This update provides a patch to fix the stack-based buffer overflow in
    libresolv that could allow specially crafted DNS responses to seize
    control of execution flow in the DNS client (CVE-2015-7547). However,
    due to a patch applied to Slackware's glibc back in 2009 (don't use the
    gethostbyname4() lookup method as it was causing some cheap routers to
    misbehave), we were not vulnerable to that issue. Nevertheless it seems
    prudent to patch the overflows anyway even if we're not currently using
    the code in question. Thanks to mancha for the backported patch.
    For more information, see:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547
    (* Security fix *)
    patches/packages/glibc-i18n-2.17-i486-11_slack14.1.txz: Rebuilt.
    patches/packages/glibc-profile-2.17-i486-11_slack14.1.txz: Rebuilt.
    patches/packages/glibc-solibs-2.17-i486-11_slack14.1.txz: Rebuilt.

    Die Kernsätze sind dabei:
    "However,
    due to a patch applied to Slackware's glibc back in 2009 (don't use the
    gethostbyname4() lookup method as it was causing some cheap routers to
    misbehave), we were not vulnerable to that issue. Nevertheless it seems
    prudent to patch the overflows anyway even if we're not currently using
    the code in question."

    Man sieht nun aber auch, dass die Slackware-Glibcen vor 14.1 nicht entsprechend gepatcht wurden.

    So, jetzt stellt Euch einmal vor, P.V. hätte auch diesen Glibc-Patch für Slackware 14.1 unterlassen und ansonsten kein Wort mehr zu dieser Lücke gesagt.

    Genau diese Art von Kommunikationskultur ist IMO eines der Hauptprobleme von Slackware.

    Zudem ist auch ersichtlich, dass Slackware nicht grundsätzlich und durchgehend Sicherheitslücken bzw. sog. "Overflows" in allen angeblich noch unterstützten Distributionsversionen patcht, ganz im Gegensatz zu Firmen wie Red Hat oder Suse.

    Ich bezweifle zudem, dass auch erfahrene Slackware-Admins jede aufgelaufenen Sicherheitslücke tracken und finden können, um diese dann gegebenenfalls selbst zu patchen. Würde man das selbst tun müssen, bräuchte man wohl einen 36-Stunden-Tag.

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung