CleanPress

Blog

  • Project Fuchsia könnte künftig Android ersetzen

    Project Fuchsia
    Bild: Google | Quelle: Flickr | Lizenz: CC0 1.0

    Seit zwei Jahren wird das Project Fuchsia auf Technik-Webseiten gerüchteweise als möglicher Nachfolger für Android gehandelt. Google hat sich dazu bisher öffentlich nie geäußert. Das gemeinhin gut unterrichtete Nachrichten-Magazin Bloomberg will nun von nicht näher bezeichneten Quellen im Fuchsia-Team bei Google Anhaltspunkte dafür haben, dass Fuchsia sogar weit mehr als ein Android-Nachfolger sein könnte.

    Android ist problembehaftet

    Demzufolge könnte Fuchsia gleich einige der Probleme lösen, die Android strukturell bedingt über die Jahre hervorgebracht hat. Zumindest zwei dieser Probleme machen Google derzeit stark zu schaffen und diese sind nicht mehr aus der Portokasse zu begleichen. Die EU hat Google am 18. Juli zu einer Rekordstrafe von 5,1 Milliarden US-Dollar verdonnert, weil das Unternehmen Android-Apps mit dem System bündelt und so den Wettbewerb behindert.

    Ein seit 2012 anhängiges Gerichtsverfahren, in dem Oracle Google wegen der Verwendung von Java-Protokollen bei Android verklagt, steht derzeit auch nicht gut für Google. Auch hier könnten eine hohe Geldstrafe und Lizenzgebühren drohen. Das Unternehmen hat bereits angedeutet, Android könne künftig für OEMs kostenpflichtig werden.

    Project Fuchsia als Neubeginn

    Laut Bloomberg sieht Google Fuchsia als eine Möglichkeit, von vorne anzufangen, um damit einige der inhärenten Fehler in Android und dem zugrunde liegenden Linux-Kernel zu beheben. Dazu gehören der Mangel an Sicherheits- und Update-Funktionen und die Schwierigkeiten bei der Integration des Google Assistant-Sprachagenten und anderer KI-Technologien.

    Keine Linux-Basis

    Fuchsia ist ein Betriebssystem, das, anders als Android, keinen Linux-Kernel als Basis benutzt. Travis Geiselbrecht, der Entwickler des als Mikrokernel ausgelegten Fuchsia-Kernels »Zircon« ließ vor rund einem Jahr durchblicken, dass es sich um ein Smartphone-Betriebssystem handele und dass es kein Spaßprojekt sei.

    Vorteihaftere Lizenzen

    Geiselbrecht hat bereits früher an den unter BSD-Lizenz stehenden Kerneln für BeOS und dem davon abgezweigten Haiku mitgearbeitet, was ein Fingerzeig auf die Verwandschaftsverhältnisse von Fuchsia sein könnte. Bei Fuchsia ist die Lizenzsituation für Google und dessen Lizenznehmer weitaus vorteilhafter. Während bei Android die GPL und eine Apache-2.0-Lizenz die Auslieferung des Quellcodes bedingen, steht Fuchsia selbst unter BSD- und der Kernel unter MIT-Lizenz. Damit würde diese Pflicht entfallen.

    Linux als Gast

    Im April hat Google unter der Bezeichnung The Book das Skelett einer Dokumentation veröffentlicht. Im Juni veröffentlichte die Website 9to5Google einen Bericht, der besagt, dass Fuchsia eine App namens Guest mitbringt, um in der Art einer Virtuellen Maschine mittels des Hypervisors im Zircon-Kernel Gast-Systeme zu starten. Dazu zählen neben Fuchsia und Chrome OS auch Linux-Systeme, wobei für Debian bereits eine eigene Guest-Anwendung bereitsteht.

    Mittels der Bibliothek »Machina« soll bei Project Fuchsia die Verbindung zwischen Host und Gast direkter sein als das bei Virtuellen Maschinen üblicherweise der Fall ist. Machina ähnelt zudem sehr dem für die Verwendung von Linux-Apps unter Chrome OS entwickelten Crostini, womit sich ein Kreis schließt.

    Vom AI-Gadget bis zum Notebook

    Laut Bloomberg haben die Entwickler des Fuchsia-Teams Pläne zum Erstellen eines Betriebssystems diskutiert, das in der Lage ist, alle internen Gadgets des Unternehmens sowie Geräte von Drittanbietern, die jetzt auf Android oder Chrome OS basieren, zu bedienen. Den Informationen nach soll Fuchsia innerhalb von drei Jahren auf Heimgeräten wie sprachgesteuerten Lautsprechern eingebettet und dann auf größere Geräte bis hin zu Laptops portiert werden, wo es Chrome OS ersetzen könnte.

    Roadmap ohne Absegnung

    Eine weitere Person innerhalb des Teams soll gesagt haben, Fuchsia könne Android theoretisch in fünf Jahren komplett ersetzen. Allerdings habe in der Konzernspitze noch niemand diese Roadmap abgesegnet. Am Project Fuchsia arbeiten aber mehr als 100 Entwickler, was die Bedeutung des Projekts klar unterstreicht.

    Kontroverses Thema Privatsphäre

    Allerdings soll es auch kontroverse Diskussionen über Design und Funktionalität geben, besonders wenn es um den Schutz der Privatsphäre geht. In dem online veröffentlichten Code zu Fuchsia haben die Ingenieure kryptografische Benutzerschlüssel in das System eingebaut – ein Datenschutz-Tool, das sicherstellt, dass private Informationen bei jeder Aktualisierung der Software geschützt sind.

    Ein durchaus heikles Thema beim durch Werbeeinnahmen finanzierten Mutterkonzern Alphabet. Sollte Android mit der Zeit wirklich abgelöst werden, so muss Google zudem darauf achten, seinen Android-Marktanteil von derzeit rund 85 Prozent nicht zu gefährden. Da es von Google bisher keine offiziellen Ankündigungen gibt, müssen wir wohl bis 2021 auf die ersten sprachgesteuerten Gadgets mit Fuchsia warten, um abzusehen, wo die weitere Entwicklung hinführen könnte.

  • Aktuelle Entwicklungen bei Fedora Workstation

    Screenshot: FThommes

     

    In der Fedora-Experimentierküche brodeln zu jeder Zeit interessante Entwicklungen. Red-Hat-Mitarbeiter Christian Schaller berichtet in unregelmäßigen Abständen über solche Entwicklungen, die dann in absehbarer Zeit in Fedora Workstation verfügbar sein werden. Jetzt bietet die kürzlich zu Ende gegangene GNOME-Entwicklerkonferenz GUADEC den Anlass für Schaller, einen neuen Bericht zu veröffentlichen.

    Wayland im Hintergrund

    Bei den meisten derzeitigen Projekten steht Wayland im Hintergrund. So etwa auch bei Remote Desktop und Desktop-Sharing. Hier stellen Unterschiede von X11 zum von Fedora Workstation seit einigen Veröffentlichungen als Standard eingesetzten Wayland-Protokoll die Entwickler vor neue Herausforderungen.

    Entfernte Desktops laden

    Jonas Ådahl arbeitet derzeit an Remote-Desktop für die GNOME-Shell. Die für Ende Oktober erwartete Veröffentlichung von Fedora 29 Workstation soll eine VNC-basierte Implementierung des Remote-Desktop bieten, weitere Protokolle wie etwa Spice sollen folgen. VNC ist zwar ziemlich veraltet, ist trotzdem noch recht weit verbreitet und anspruchslos im Einsatz. Um die Wayland-Sitzung über VNC zu teilen kommt das Multimedia-Framework PipeWire zum Einsatz, das vom GStreamer-Pionier Wim Taymans entwickelt wird.

    Desktop-Sharing per WebRTC

    Jan Grulich, Tomas Popela und Eike Rathke arbeiten seit geraumer Zeit am Desktop-Sharing unter Wayland mit Firefox und Chromium unter Zuhilfenahme von WebRTC. Auch hier spielt PipeWire das Bindeglied, indem die Browser jeweils ein PipeWire-Backend erhalten. Eine gepatchte Firefox-Version steht bereits seit einiger Zeit zum Testen für Fedora 28 und Fedora Rawhide bereit.

    PipeWire

    Auf der GUADEC 2017 hielt Entwickler Wim Taymans einen Vortrag über die Ideen hinter und den Entwicklungsstand von PipeWire. Hier wird unter anderem beständig an der Nachbildung der Funktionalität des professionellen Audio-Servers Jack gearbeitet. Die Player Totem und Rhythmbox können zum Abspielen von Audio über PipeWire mit dem PulseAudio-GStreamer-Plugin genutzt werden, nachdem ein Ersatz für die libpulse.so implementiert wurde.

    Im Herbst wird ein PipeWire und Linux Audio Hackfest stattfinden, bei dem die Teams von  PipeWire, GStreamer, Totem, GNOME Control Center, PulseAudio und Jack über die weitere Entwicklung von PipeWire diskutieren.

    GNOME Builder im Container

    GNOME Builder, die integrierte Entwicklungsumgebung, die seit einiger Zeit in den GNOME-Desktop integriert ist, wird maßgeblich von Christian Hergert entwickelt. Die derzeitige Entwicklung geht in Richtung Unterstützung für die Entwicklung hin zu Embedded-Geräten wie dem kommenden Linux-Smartphone Purism 5. Christian erwähnte zudem in seinem GUADEC-Vortrag, dass Builder wahrscheinlich die erste »Container Native IDE«  der Welt ist, indem es einerseits mit dem Ziel entwickelt wird, als Flatpak verteilt zu werden, als auch, Flatpaks als primäres Ausgabeformat zu erstellen.

  • OwnCloud 10.0.9 erhöht die Flexibilität mit »Pending Shares«

    OwnCloud 10.0.9
    Bild: ownCloud2-Logo | Quelle: Wikimedia | Lizenz: AGPL

     

    OwnCloud, eine Anwendung zum Speichern, Synchronisieren und Austauschen von Daten auf einem eigenen Server hat Version 10.0.9 vorgestellt. Die neue Version bringt zahlreiche Verbesserungen, erhöht die Flexibilität und verbessert die Passwort-Richtlinien.

    Mehr Kontrolle und Flexibilität

    OwnCloud Server 10.0.9 führt unter anderem eine neue Funktion ein, um und den Benutzern mehr Kontrolle über eingehende Freigaben zu geben. Bisher wurden freigegebene Inhalte unangekündigt in der Dateihierarchie des empfangenden Benutzers angezeigt und die Clients begannen mit der Synchronisierung. Eingehende Freigaben können mit der Einführung der Funktion »Pending Shares« nun einen schwebenden Zustand haben, der dem Anwender die Möglichkeit bietet, anstehende Freigaben komplett oder selektiv anzunehmen oder abzulehnen.

    Bessere Übersicht

    Neben der Funktion »Pending Shares« bietet der OwnCloud-Server nun auch die Möglichkeit, akzeptierte, ausstehende und abgelehnte Freigaben anzuzeigen. Mithilfe des Filters Mit Dir geteilt in der Seitenleiste der Dateiansicht können Benutzer nun alle eingehenden Freigaben mit ihren jeweiligen Zuständen auflisten und einfach zwischen den Zuständen wechseln. Diese Verbesserung ermöglicht es nicht nur, zuvor abgelehnte Freigaben nachträglich zu akzeptieren, sondern auch zuvor nicht freigegebende Shares wiederherzustellen, ohne dass der Eigentümer sie erneut freigeben muss.

    Passwortrichtlinie für alle

    Eine Funktion, die bisher zahlenden Kunden vorbehalten war, ist mit Owncloud 10.0.9 nun auch in der Community-Version verfügbar. Es handelt sich dabei um die »Password Policy Extension«, eine erweiterte Passwort-Richtlinie, die nun unter der GPLv2 steht.  Die neue Richtlinie unterstützt nun Passwort-Verfalls- und Verlaufsrichtlinien für alle Benutzerkonten. So kann ein Administrator unter anderem festlegen, wie oft Anwender ein Passwort erneuern müssen und kann bereits benutzte Passwörter von der Verwendung ausschließen.

    Neuer Ansatz beim Object Storage

    Ebenfalls für die Community freigegeben wurde S3 Object Storage. Mit der Integration des S3-Protokolls erhalten alle Anwender von Owncloud die Möglichkeit, Object-Speicherung zu verwenden. Gleichzeitig wird die Unterstützung des OpenStack-Swift-Protokolls zur verteilten Speicherung von Daten als veraltet eingestuft.

    OwnCloud wurde 2010 von KDE-Entwickler Frank Karlitschek entwickelt, um Daten unter eigener Kontrolle vorhalten, synchrionisieren und austauschen zu können. Im Jahr 2016 verließ Karlitschek mit der Mehrzahl der Entwickler das Unternehmen und gründete den Konkurrenten Nextcloud. Hauptunterscheidungsmerkmal ist, dass Nextcloud alle Entwicklungen von vornherein der Community frei zur Verfügung stellt.

    Eine Übersicht über sämtliche Änderungen zu Owncloud 10.0.9 sind in den Release Notes  und in Changelog zu finden. OwnCloud 10.0.9 steht zum Download auf der Webseite des Herstellers zur Verfügung.

  • Ein Vierteljahrhundert Slackware

    Slackware
    Bild: Slackware 14.1 | Quelle: Phillip Lacroix | Lizenz: GPL

    Slackware ist ein Vierteljahrhundert alt und damit die älteste noch aktive Linux-Distribution. Gestern vor 25 Jahren kündigte Patrick J. Volkerding, Gründer von Slackware, in einem Usenet-Posting die Version 1.00 der Distribution an. Diese basierte damals auf Torvalds Kernel 0.99.10 und stand mit einem Umfang von insgesamt 24 Disketten per FTP zum Download bereit.

    Knapp vor Debian

    Eigentlich wollte Volkerding keine Linux-Distribution ins Leben rufen, sondern Installation und Konfiguration der Distribution Softlanding Linux System (SLS) verbessern, die bereits ein Jahr zuvor von Peter MacDonald veröffentlicht worden war. Als er damit kein Glück hatte, veröffentlichte er SLS mit seinen Änderungen als Slackware. Ian Murdock, ein weiterer unzufriedener SLS-Nutzer, startete wenig später Debian. Slackware bildete unter anderem die Grundlage für die ersten Veröffentlichungen von SuSE Linux.

    Alleinherrscher Volkerding

    Volkerding bestimmte damals wie heute als Ein-Mann-Show die Geschicke von Slackware, trifft alle Entscheidungen und ist sehr aktiv in der Slackware-Community. Er lehnt die Distribution möglichst nah an Unix an. So gibt es bei Slack, wie die Distribution auch genannt wird, keine distributionsspezifischen Werkzeuge für die Konfiguration. Die Webseite postuliert »Benutzerfreundlichkeit und Stabilität«  als Ziele der Distribution. Dabei sollte Benutzerfreundlichkeit im Sinne von Einfachheit verstanden werden, denn Slack besitzt keinen grafischen Installer und der Paketmanager kennt keine automatische Auflösung von Abhängigkeiten.

    Einfach und zuverlässig

    Das stört die Slacker, wie die Fans der Distribution genannt werden, wenig. Aber es stellt in der heutigen Zeit das geistig verwandte Arch Linux in ein anderes Licht, bedenkt man dessen Ruf als schwierig. Slackware hat keinen öffentlichen Bug-Tracker, kein Code-Repository und keine festgelegte Einbindung der Community.

    Slack-Derivate

    Volkerding veröffentlicht den Rolling-Release-Zweig  current, wann immer er es für angebracht hält und wird dabei von ein paar wenigen Helfern unterstützt. Wichtig ist für viele Slacker, dass Volkerding sich bisher erfolgreich gegen die Integration von Systemd wehren konnte. Slackware hat unter anderem Derivate wie Absolute Linux, Frugalware, Slax, Salix OS und Porteus hervorgebracht.

    Die aktuelle Veröffentlichung ist Slackware 14.2, das neben Kernel 4.4.14 und X11 R7.7 als Desktop sowohl Xfce 4.12.1 als auch KDE 4.14.21 anbietet und Installation und Booten per UEFI unterstützt. Die anhaltende Beliebtheit von Slackware bei den Fans beruht vermutlich darauf, dass Slack dem Fortschritt nicht abgeneigt ist, aber nicht jedem Trend hinterherrennt.

  • Ubuntu Snaps – das Sandbox-Modell

    Ubuntu Snaps
    Bild: Sandbox | Quelle: Simon Law Lizenz: CC BY-SA 2.0

     

     

    Canonical hat mit Ubuntu Snaps ein Paketformat entwickelt, das seine Vorteile hauptsächlich im Internet der Dinge und in eingebetteten Systemen ausspielen soll, aber auch auf dem Desktop zunehmend Verbreitung findet. Durch seine plattform-unabhängige Eigenständigkeit erlaubt es beispielsweise das Testen von aktuellen Versionen von Software, die unter der verwendeten Distribution noch nicht verfügbar sind. Entwickler können damit ihre Software in ein Paket stecken, das auf allen Plattformen lauffähig ist, die das Snap-Format unterstützen.

    Ubuntu Snaps im Sandkasten

    Aus Sicherheitsgründen arbeiten Snaps, wie auch das alternative Flatpak-Format in sogenannten Sandboxen. Das bedeutet, die Anwendung ist eingesperrt und erhält nur die notwendigen Zugriffe auf das Gast-System. Aus Entwicklersicht gibt es drei Stufen der Beschränkung, die mit Devmode, Classic und Strict betitelt sind. Was der Endanwender erhält, wenn er ein Snap aus der Abteilung Stable des Ubuntu-Snap-Store installiert, entspricht immer Strict.

    Strict-Mode

    Snaps, die nach dem Strict-Mode erstellt wurden können ohne manuelle Überprüfung in den Store hochgeladen werden. Das Strict-Modell beschränkt eine Applikation mittels Sicherheitsfunktionen des Kernels. Werden hier keine Ausnahmen definiert, hat die App keinerlei Zugriff auf das System. Diese Ausnahmen heißen Interfaces und stellen Schnittstellen für den Zugriff der App auf definierte Bereiche des Gast-Systems dar.

    Devmode

    Um funktionierende Ubuntu Snaps zu erstellen, in denen diese Schnittstellen der kasernierten App die nötigen Zugriffe erlauben, steht Entwicklern der Devmode zur Verfügung. Mit dieser Einstellung erstellte Snaps sind zunächst nicht in ihrem Zugriff beschnitten, der Entwickler kann also beim Testen Schnittstellen suchen, die den nötigen Zugriff erlauben und den Rest einschränken. Wird eine noch nicht definierte Schnittstelle benötigt, kann der Entwickler diese per Bugreport anregen. Snaps im Devmode können lediglich in den Kanälen Edge und Beta veröffentlicht werden und stehen somit zur Durchsicht und Qualitätssicherung bereit.

    Classic-Mode

    Das Modell Classic bietet der Anwendung in einem Snap alle Zugriffe auf das System, die auch eine Anwendung ohne Snap-Beschränkung hat. Dieser Modus bietet Entwicklern die Möglichkeit, Anwendungen als Snap auszuliefern, die noch nicht als Schnittstelle definierte Zugriffe benötigen. Stehen diese Schnittstellen später zur Verfügung, kann der Entwickler auf Strict wechseln.

    Snaps nach dem Classic-Modell werden manuell überprüft bevor sie im Stable-Channel des Ubuntu-Snap-Store veröffentlicht werden. Sie dürfen allerdings keine Verwendung im Ubuntu-Core finden. Anwender haben bei der Installation eines Snap die Möglichkeit, das vom Entwickler vorgegebene Level an Beschränkung zu übergehen, indem sie etwa den Schalter -classic verwenden. Das ist allerdings nicht ratsam, denn es entfernt alle definierten Interfaces und erlaubt der Anwendung ungehinderten Zugriff.

    Mehr zu diesem Thema vermitteln ein Blogeintrag von Alan Pope, nochmals vertieft in der Snapcraft-Dokumentation.

     

  • Debian GNU/Linux 9.5 erschienen

    Debian GNU/Linux 9.5 erschienen

    Debian 9.5
    Screenshot: ft

     

    Debian 9.0 »Stretch« erschien am 16.6. 2017 und erhielt jetzt mit Debian 9.5 sein fünftes Punkt-Update. Debian 9.4 erschien Mitte März. Wie üblich bei Debian werden mit den Punkt-Releases über die Laufzeit einer Veröffentlichung Sicherheitsupdates verteilt und Fehler in Paketen behoben, wenn dies möglich ist, ohne Regressionen hervorzurufen.

    Neuer Intel-Microcode

    Debian 9.5 ist vergleichsweise groß ausgefallen und bringt 100 Sicherheits-Updates und 91 behobene Fehler in Paketen. Unter anderem erhält Debian 9.5   »Stretch«  damit einen neuen Intel-Microcode mit der Versionsnummer 3.20180425.1~deb9u1, der auch Code zum Schutz gegen die Prozessor-Lücke Spectre v2 enthält. Neben der Auslieferung des neuen Kernel 4.9.110 und einem Update für den  Debian-Installer wurden auch Pakete wie apache2, base-files, clamav, dpkg, reportbug und systemd von Fehlern befreit.

    Sicherheit verbessert

    Bei der Verbesserung der Sicherheit erhielt Firefox-ESR insgesamt sechs Security-Updates, unter anderem gefolgt von Xen mit vier und Thunderbird mit zwei Vorfällen. Weiterhin betroffen war auch hier der Webserver Apache2 ebenso wie WordPress Drupal7, Gnupg1 und 2. Alle Sicherheits-Updates wurden bereits in einem »Debian Security Advisory« (DSA) beschrieben.

    Bitte aktualisieren

    Insgesamt fassen die Debian-Punkt-Releases die Sicherheitsupdates und Fehlerkorrekturen seit dem jeweils letzten Punkt-Release zusammen. Anwender, die ihr System regelmäßig aktualisieren, haben die meisten Sicherheits-Aktualisierungen bereits erhalten. Ein Debian-Punkt-Release erfordert keine Neuinstallation des Systems. Die neuen Pakete können über die Paketverwaltung aktualisiert werden.

    Frische Images

    Erste aktualisierte Images für Anwender, die trotzdem eine neue Installation vornehmen möchten stehen auf den Download-Servern zur Verfügung, weitere werden in den nächsten Tagen folgen. Bis im nächsten Jahr die nächste Debian-Veröffentlichung Debian 10 »Buster« erscheint, werden vermutlich eine weitere Handvoll Punkt-Releases folgen.

  • Guido van Rossum: Eine Ära geht zu Ende

    Guido van Rossum
    Bild: Guido van Rossum | Quelle Daniel Stroud | Lizenz: CC BY-SA 4.0
    Guido van Rossum, der Autor der Programmiersprache Python, ist überraschend von der Projektleitung zurückgetreten. Das teilte er seinen Kollegen in einer Mail an die Python-Entwicklerliste mit. Bis zu seinem Rücktritt galt er als Benevolent Dictator For Life (BDFL), als wohlwollender Diktator auf Lebenszeit.

    Fast 30 Jahre

    Der Niederländer van Rossum lenkte die Geschicke von Python, der laut Umfragen beliebtesten Programmiersprache der Welt, seit 1989 für fast 30 Jahre, bevor er nun das Zepter niederlegte. Er verlässt das Projekt nicht endgültig, sondern verbleibt nach eigener Aussage noch eine Weile als »gewöhnlicher Kern-Entwickler« und als Mentor für Neueinsteiger in die Entwicklung. Mit den Entscheidungsprozessen innerhalb des Projekts will er aber nichts mehr zu tun haben. Ausschlaggebend für seinen Weggang war nach seinen Worten das heftige Ringen um eine Entscheidung über PEP 572, einen Erweiterungsvorschlag, der letztlich durch ein Machtwort von van Rossum entschieden werden musste.

    »So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?« – Guido van Rossum

    Der 62-jährige van Rossum führt in seiner Mail unter anderem auch gesundheitliche Probleme an, aber aus einigen Aussagen lässt sich klar herauslesen, dass Rossum müde ist, mit den Kollegen über  Entscheidungen zu ringen und dass es Konflikte im Führungsgremium gibt. Er bestimmt keinen Nachfolger und überlässt seine Hauptentwickler sich selbst. Er sieht keine Probleme in den täglich zu treffenden Entscheidungen, das könne weiter gehen wie bisher.

    Konfliktpotenzial erkannt

    Probleme sieht van Rossum eher darin, wie künftig die sogenannten Python Enhancement Proposals (PEPs), also die Vorschläge zur Weiterentwicklung von Python, und die Bestallung neuer Hauptentwickler entschieden werden. Hier sieht van Rossum Konfliktpotenzial. Er erinnerte die Entwickler daran, dass Python einen »Community Code of Conduct« (CoC) hat, und fügte hinzu: »Wenn Euch dieses Dokument nicht gefällt, besteht Eure einzige Möglichkeit darin, diese Gruppe freiwillig zu verlassen«.

    Suche nach neuem Führungsmodell

    Während die Entwickler hoffen, van Rossums Weggang sei lediglich vorübergehend, so schauen sie sich gleichzeitig bei anderen Open-Source-Projekten nach einem möglichen neuen Führungsmodell um. Ein mögliches Szenario dabei ist, eine Dreierspitze zur Führung des Projekts einzusetzen. Es bleibt zu hoffen, dass Python seine Führungskrise schnell überwindet undabei keinen Schaden nimmt. Van Rossum arbeitete von 2005 bis 2012 bei Google, wo er die Hälfte seiner Zeit in die Weiterentwicklung von Python stecken konnnte. Seit 2013 arbeitet er bei Dropbox.

  • Chrome 67 verstärkt die Sicherheit mit Seiten-Isolierung

    Chrome 67
    Bild: google_chrome | Quelle jibunkaiwai | Lizenz: CC BY 2.0

     

    Mit Chrome 67 dreht Google weiter an der Sicherheitsschraube. Das neueste Feature im Kampf gegen Spectre & Co. heißt Site Isolation, zu deutsch Seiten-Isolierung. Mit der Sicherheit erhöht sich allerdings auch der RAM-Bedarf des Browsers.

    Verschärfte Trennung

    Mit Site Isolation verschärft Google die Trennung von Inhalten im Browser. Galt bisher die Maxime, dass jeder Tab in einem eigenen Prozess läuft, so verfeinert Google nun diese Aufteilung weiter. Mit der bisherigen Lösung liefen etwa Cross-Site-Iframes oder -Pop-Ups im gleichen Prozess wie die Seite, die sie erzeugt hatte. Das erlaubte einem erfolgreichen Spectre-Angriff unter Umständen, Daten wie unter anderem Cookies oder Passwörter anderer Frames oder Pop-ups zu lesen.

    Spectre-Angriffe erschweren

    An Site Isolation arbeitete Google schon lange, bevor die Spectre-Angriffe Furore machten. Dabei geht es um eine einschneidende Änderung der Chrome-Architektur, die jeden Rendering-Prozess auf Dokumente von einer einzigen Seite beschränkt. Dies bedeutet, dass alle Navigation zu Cross-Site-Inhalten den jeweiligen Tab zum Wechseln der Prozesse veranlasst. Es bedeutet auch, dass alle Cross-Site-Iframes in einen anderen Prozess als ihr übergeordnetes Frame gesetzt werden, indem out-of-process iframes verwendet werden.

    Site Isolation für (fast) alle

    Mit Chrome 67 ist Site Isolation für 99 Prozent der Nutzer auf allen Betriebssystemen aktiviert, das verbleibende eine Prozent dient als Kontrollgruppe. Mit der Aktivierung reduziert sich die Datenmenge, die ein Angreifer stehlen könnte, und »reduziert die Bedrohung durch Spectre erheblich«, so Google.

    Kehrseite der Medaille

    Google plant, die Site Isolation auf Chrome für Android auszudehnen und arbeitet an der Lösung bekannter Probleme. Mit Chrome 68 kann die Seiten-Isolierung sowohl manuell auf dem Handy über ein Flag als auch über Unternehmensrichtlinien aktiviert werden. Wie so oft, hat aber auch diese Verbesserung einen Pferdefuß: Dadurch, dass mehr Rendering-Prozesse erzeugt werden, erhöht sich der RAM-Verbrauch des beliebtesten Browsers weiter. Google-Entwickler Charlie Reis führte das im Sicherheitsblog des Unternehmens aus:

    Site Isolation führt dazu, dass Chrome mehr Rendering-Prozesse erstellt, was mit Leistungseinbußen verbunden ist: Auf der positiven Seite ist jeder Rendering-Prozess kleiner, kurzlebiger und hat intern weniger Konkurrenz, aber es gibt aufgrund der größeren Anzahl von Prozessen etwa 10-13 Prozent Gesamtspeicher-Overhead in realen Workloads. Unser Team arbeitet weiterhin hart daran, dieses Verhalten zu optimieren, um Chrome schnell und sicher zu halten.

  • Ubuntu-Fehler: Sperrbildschirm kann umgangen werden

    Ubuntu-Fehler
    Bild: Security | Quelle GotCredit | Lizenz: CC BY-2.0

     

    Hacker können Zugriff auf laufende Anwendungen auf einem Ubuntu-Rechner erhalten, wenn Sie physischen Zugriff auf dessen Festplatte haben. Dieser bereits am 18. Juni gemeldete und erst  jetzt bekannt gewordene Ubuntu-Fehler betrifft alle Versionen seit Ubuntu 14.04 LTS »Trusty Tahr«.

    Vermutlich sind aber auch die Derivate der Ubuntu-Familie (bestätigt für 18.04 MATE) als auch Ableger wie Linux Mint und andere betroffen. Dabei besteht Zugriff auf offene Anwendungen des Anwenders, bevor dieser das Gerät in den Ruhemodus schickt.

    Kritischer Ubuntu-Fehler

    Wenn der Angreifer die Festplatte, auf der sich die Installation befindet, während des Ruhemodus (suspend) entfernt und dann das Gerät aufweckt, gibt es mehrere Möglichkeiten: Der Sperrbildschirm erscheint und die Eingabe eines beliebigen Passworts erlaubt den Zugriff. Wenn das beliebige Passwort nicht angenommen wird, kann der Ausschaltknopf der Hardware betätigt und dadurch der Zugriff erreicht werden. Bleibt der Bildschirm dunkel, kann der Vorgang, beginnend mit dem Ruhemodus des Rechners wiederholt werden.

    Die erste Stellungname eines Canonical-Security-Ingenieurs liest sich nicht gerade beruhigend:

    [su_quote style=“modern-light“ cite=“Marc Deslauriers“]Es ist unwahrscheinlich, dass wir dies beheben werden, da ein Angreifer mit einem physischen Zugriff einfach direkt auf die Festplatte zugreifen oder das Passwort auf der Festplatte ersetzen und den Computer entsperren kann.[/su_quote]

    Auch wenn dies so richtig ist, das Entfernen der Festplatte eines Rechners erfordert lediglich mechanisches Geschick und kein Wissen wie man das Passwort ersetzt. Es ist ein einfach klingender Hack und er funktioniert, indem er einen Fehler in der Art und Weise ausnutzt, wie das System Daten speichert, wenn Ubuntu im Ruhezustand ist.

    Ein weiterer in diesem Zusammenhang aufgetauchter Fehler erlaubt manchmal das Umgehen des Sperrbildschirms durch Anschließen eines HDMI-Monitors, sobald der Sperrbildschirm auftaucht.

    AMD-Microcode zurückgezogen

    Erst gestern wurde ein anderes Sicherheitsproblem bei Ubuntu 14.04 LTS »Trusty Tahr« beseitigt, indem der vorherige unsichere Zustand wieder hergestellt wurde. Der am 20. Juni ausgelieferte AMD-Microcode musste zurückgezogen werden, da er durch eine Regression vereinzelt den Bootvorgang von Rechnern unterbrach und diese somit nutzlos machte.

    Der AMD-Microcode sollte eigentlich den Auswirkungen der Anfang Januar bekannt gewordenen Spectre-Lücke (CVE-2017-5715) entgegenzuwirken. Nun zog Canonical den Microcode zurück, indem das Paket amd64-microcode 3.20180524.1~ubuntu0.14.04.2+really20130710.1 an seine Stelle rückte.

  • Plasma-Desktop-Verbesserungen im Juni

    Plasma-Desktop-Verbesserungen im Juni

    Plasma Desktop
    Screenshot

    Im wöchentlichen Rhythmus veröffentlicht KDE-Entwickler Nate Graham unter dem Titel Usability and Productivity die Arbeit des Teams bei der Verbesserung des Plasma-Desktops. In den vergangenen Wochen gab es wieder einige interessante Einträge.

    Discover verbessert

    Das begann mit einer Änderung bei Plasmas Software-Installer Discover. Die Anwendung kann jetzt auf Wunsch anzeigen, welche Abhängigkeiten die Installation eines Pakets nach sich ziehen würde. Bei System-Updates zeigt Discover an, welche Pakete entfernt oder ersetzt werden sollen. Es verhindert künftig zudem, dass der Anwender sich ohne Warnung abmelden kann, während Discover noch Pakete installiert. Das führte bisweilen zu inkonsitentem Verhalten nach Wiederanmelden.

    Kontroverse Änderung zurückgenommen

    Für Aufregung hatte im letzten Jahr eine Änderung gesorgt, die der ehemalige KWin-Entwickler Martin Flöser eingeführt hatte. Er verhinderte damit, dass Anwendungen wie Dolphin, Kwrite oder Kate als Root gestartet werden konnten. Viele Anwender sahen dies als unter Linux unzulässige Bevormundung an. Jetzt hat Nate Graham diese Beschränkung wieder aufgehoben, zuminmdest bei Dolphin aber eine Warnung eingefügt.

    [su_slider source=“media: 5648,5652,5650,5656,5655,5654,5653″ limit=“12″ link=“lightbox“ width=“960″ height=“960″ autoplay=“0″ speed=“0″]

    Dolphin kann teilen

    Dolphin erhält zudem die beiden neuen Kontextmenüeinträge Sort by und View Mode. Wird künftig eine Datei in Dolphin umbenannt und der neue Name liegt außerhalb des Blickfelds, scrollt Dolphin automatisch dorthin. Eine weitere Verbesserung erhält Dolphin im Kontextmenü. Wie Spectacle und Okular erhält der Dateimanager einen Share-Eintrag zum Teilen mit verschiedenen Diensten.

    Bildwerkzeuge lernen dazu

    Beim Bildbetrachter Gwenview können Bilder nun per Drag&Drop angezeigt werden. Zudem können angezeigte Bilder mit der Maus in andere Anwendungen gezogen werden. Das Screenshot-Tool Spectacle kann jetzt Bilder via  KDE Connect an Smartphones übergeben. Per Spectacle mit Imgur geteilte Bilder senden den entsprechenden Link nun zurück in die Zwischenablage.

    Alle erwähnten Änderungen fließen in KDE Applications 18.08.0 ein, das am 16. August veröffentlicht werden soll. Für Plasma 5.14 wurde in den Systemeinstellungen zudem das Libinput-Backend für Maus und Touchpad optisch und funktional überarbeitet.