LN-Waschpress

Autor: sla

  • 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.

     

  • Einbruch bei Gentoo durch Achtlosigkeit ermöglicht

    Einbruch bei Gentoo
    Photo by Anas Alshanti on Unsplash

     

    Die Analyse des Einbruchs und der Übernahme des GitHub-Repositories der Linux-Distribution Gentoo ist abgeschlossen. Aus dem jetzt vorliegenden schriftlichen Report lassen sich zwei Kernaussagen ableiten.

    Vorbildliche Reaktion

    Zum einen haben die Entwickler vorbildlich reagiert und sind sofort nach der Entdeckung an die Öffentlichkeit gegangen. Zweitens wurde der Einbruch durch ein kompromittiertes Passwort auf einer anderen Webseite erst ermöglicht. Wie die Entwickler feststellten, konnte das Passwort für den Hack von dem kompromittierten Passwort abgeleitet werden. Einer der Entwickler verwendete ähnliche Passwörter auf verschiedenen Webseiten und Diensten.

    Drei Repositories betroffen

    Der oder die Einbrecher hatten nach dem Eindringen zunächst alle legitimen Accounts entfernt und dann versucht, durch das Hinzufügen von rm -rf-Kommandos in verschiedenen Repositories Daten auf den Rechnern der Nutzer zu löschen, die per git pull diese Repositories auf ihre Rechner ziehen. An dieser Stelle waren allerdings Sicherheitsmaßnahmen eingebaut, die das Ausführen dieser Befehle verhinderten. Betroffen von den Änderungen der Einbrecher waren die Repositories gentoo/gentoo, gentoo/musl und gentoo/systemd. Kopien dieser Repositorien aus dem betroffenen Zeitraum sollten auf keinen Fall genutzt werden.

    Schwachstellen identifiziert

    Die Analyse hat einige Schwachstellen in der Handhabung der GitHub-Repositories seitens der Gentoo-Entwickler aufgezeigt. So sei unter anderem die Kommunikation mit Anwendern der betroffenen Repositories nicht ideal gewesen. Zudem war der Mechanismus zum Widerruf der Zugangsdaten schlecht implementiert. Es gab darüber hinaus kein Backup der Details der Gentoo-Organisation auf GitHub. Systemd, eines der drei betroffenen Repositories, war kein Spiegel eines Gentoo-Repository, sondern direkt auf Github gespeichert.

    Auswirkungen

    Die Gentoo-Organisation auf GitHub war als Folge des Einbruchs für fünf Tage gesperrt. Eine unangenehme Folge des Einbruchs war zudem, dass alle früheren Pull Requests  von den zugehörigen Commits getrennt und geschlossen wurden. Das konnte von GitHub nicht rückgängig gemacht werden, sodass Anwender ihre Pull Requests erneut öffnen müssen.

    Laute Einbrecher

    Die Attacke verlief relativ laut, was zur schnellen Entdeckung beitrug. Einerseits wurden durch das Entfernen aller Konten die Entwickler per E-Mail informiert. Zum anderen erzwangen der oder die Täter ihre Änderungen mit dem Kommando git push –force. Damit hatten die Einbrecher selbst verhindert, dass ihre Änderungen lautlos von Anwendern mit einem git pull auf ihre Rechner gezogen werden konnten.

    Lehren gezogen

    Der Originalcode von Gentoo war zu keinem Zeitpunkt gefährdet, da er sich auf Servern der Organisation befindet, auf GitHub liegt lediglich eine Kopie. Die Entwickler selbst arbeiten fast ausschließlich mit dem Originalcode, während Beiträge aus der Community auch über die Gentoo-GitHub-Organisation vorgenommen werden. Als eine der Lehren aus dem Vorfall forciert Gentoo jetzt die Verwendung von Zwei-Faktor-Authentifizierung (2FA) für Konten auf GitHub. Viele Anwender nutzten diese doppelte Absicherung bereits vor dem Vorfall, aber nicht alle.

  • Udoo Bolt – Mini-Board mit AMD Ryzen Embedded V1000

    Udoo Bolt
    Quelle: Kickstarter

     

    Auf Kickstarter wird zur Zeit der leistungsstarke Einplatinen-Computer Udoo Bolt finanziert. Dabei handelt es sich um das bisher leistungsstärkste Mini-Board. Das mit einem AMD Ryzen Embedded aus der Baureihe V1000 ausgerüstete Board kann unter anderem als potentes Maker-Board oder als Workstation, auf der auch AAA-Spiele laufen, eingesetzt werden.

    Potente Hardware

    Die verwendete AMD Ryzen Embedded V1202B-SoC mit vier zwei Kernen und vier Threads leistet 3.2 GHz und inkludiert zudem eine Radeon-Vega-3-GPU ab. Das Board selbst ist zur Arduino-Plattform kompatibel, sodass es sich auch für Robotik und andere Elektronikprojekte eignet. Andererseits kann das von Hause aus mit 32 GByte eMMC-Speicher ausgestattete mit bis zu 32 GByte SO-DIMM mit 2.400 MHz in zwei Sockeln bestückt werden und als Workstation eingesetzt werden. Das Board bietet sich dafür auch an, weil es bis zu vier Monitore mit 4K-Ultra- HD ansteuern kann. Als Betriebssystem kann Windows oder eine beliebige Linux-Distribution installiert werden. Neben dem Udoo Bolt V3 gibt es zudem eine noch potentere Variante Udoo Bolt V8 mit AMD Ryzen Embedded V1605B-SoC.

    Viele Schnittstellen

    An Schnittstellen herrscht bei beiden Boards kein Mangel. Neben zwei USB-3-A-Ports sind auch zwei USB-C-3.1-Gen2-Ports verbaut, die auch im DisplayPort-Mode betrieben werden können. Zudem gibt es zwei Eingänge für HDMI-2.0 und einen GBit-Ethernet-Port. Für Arduino steht ein kompatibler Pin-Out bereit. Neben zwei Speicherbänken für die SO-DIMM-Module bietet die Rückseite des Boards die M.2-Sockets für die Formfaktoren 2260 und 2280 für PCIe. Zudem ist ein SATA-3.0-6GBit/s-Verbinder verfügbar.

    Preisgestaltung des Udoo Bolt

    Die Preise für die vielen Varianten des laut Planung im Dezember auszuliefernden Boards beginnen bei 229 US-Dollar. Dafür bekommt der Kunde das nackte Board samt CPU-Lüfter. RAM und Netzteil sind dabei nicht im Lieferumfang. Für 402 US-Dollar wird ein Paket angeboten, das neben dem Board auch 2 x 4 GByte RAM, ein Intel-WLAN- und Bluetooth-Modul inklusive Antenne, ein Netzteil, HDMI- und SATA-Kabel sowie ein Metallgehäuse enthält.

    Die KickStarter-Kampagne war auf 100.000 US-Dollar ausgelegt, derzeit sind bei noch 23 Tagen Laufzeit bereits über 550.000 Dollar eingegangen. Übersteigt die zugesagte Summe 800.000 Dollar, wird der verbaute eMMC-Speicher von 32 auf 64 GByte erhöht.

    Erfahren beim Crowdfunding

    Udoo hat bereits viel Erfahrung mit erfolgreicher Schwarmfinanzierung sammeln können. Vor fünf Jahren erschien das erste Board unter der Bezeichnung Udoo. Die Udoo-Boards entstammen einer Zusammenarbeit der Firmen SECO und AIDILAB. 2013 wurde als erstes Board das Udoo Quad auf Kickstarter finanziert, weitere folgten. Die ersten Boards setzten auf  i.MX6-CPUs von NPX und richteten sich dank Arduino-Kompatibilität hauptsächlich an die Maker-Szene. Mit dem X86 setzten die Entwickler danach erstmals auf einen Intel Pentium N3710 und erweitern damit das Einsatzspektrum.

     

  • Screensharing unter Wayland erklärt

    Screensharing unter Wayland erklärt

    Bereits im März berichteten wir über die Bemühungen von Red-Hat-Entwickler Jan Grulich, Screensharing für KDE-Plasma unter Wayland zu realisieren. Da Wayland im Gegensatz zu X11 kein Netzwerkprotokoll ist, müssen für das Screensharing unter Wayland neue Wege gefunden werden. Dafür hatte Grulich bereits Backends in Form von xdg-desktop-portal und xdg-desktop-portal-[kde/gtk] für KDE-Plasma und die GNOME-Shell geschrieben und das Audio-Video-Framwork PipeWire zum Streamen auserkoren. Was fehlte, war eine Anwendung, mit der ein User Screensharing auch nutzen konnte.

    WebRTC als Screensharing-Anwendung

    Seit einigen Wochen arbeitet Grulich mit zwei Kollegen, daran, für diese Aufgabe die in Browsern verwendete Videochat-Technik WebRTC nutzbar zu machen, wie er jetzt in seinem Blog berichtet. WebRTC verwendet eine Klasse namens DesktopCapturer, die sowohl unter X11 als auch den Gegenstücken bei Windows oder macOS Verwendung findet. Diese Klasse hat das Team nun für Wayland aufgebohrt.

    Alle Bauteile zusammen

    Die Umsetzung dieser Idee unter Verwendung der Portals für Plasma und GNOME sowie PipeWire als Streaming-Agent konnte relativ einfach umgesetzt werden. Dank der Backend-Portals wird diese Technik auch in Sandboxen in Flatpak oder Snap funktionieren. Allerdings müssen die leicht unterschiedlichen Herangehensweisen der Browser an WebRTC noch angepasst werden, bevor der Code produktiv genutzt werden kann. Für Neugierige hat Grulich für Fedora ein Repository aufgesetzt, dass einen Firefox mit den entsprechenden Änderungen enthält.  Voraussetzung ist lediglich ein funktionierendes PipeWire.

    Screensharing unter Wayland

    Ein zweiter Blogeintrag von Grulich geht in die Praxis und erläutert schrittweise, wie Screensharing mit Wayland bereits jetzt auch außerhalb von Fedora genutzt werden kann. Wird der Plasma-Desktop verwendet, so wird hier Version 5.13.2 vorausgesetzt. Sowohl die GNOME-Shell als auch Plasma brauchen noch ein wenig Anpassung, wie Grulich erläutert. Der Blogeintrag bietet zudem für Interessierte am Ende einige Verweise, die das grundlegende Verständnis der verwendeten Techniken vertiefen sollen.