Das MLS-Protokoll soll sichere Gruppenchats mit Tausenden Teilnehmern ermöglichen und die Grundlage für Messenger-Interoperabilität werden.

Die Internet Engineering Task Force (IETF) hat auf ihrem aktuellen Treffen der Veröffentlichung des Standards für das Protokoll Messaging Layer Security (MLS) zugestimmt. Das kündigt die IETF in ihrem Blog an. Damit enden mehr als fünf Jahre Arbeit an dem Protokoll, das erstmals wichtige Teile der Verschlüsselung für Messenger übergreifend standardisiert und so auch Grundlagen für eine mögliche Interoperabilität zahlreicher Chat-Systeme schafft.

In der Ankündigung heißt es: “Damit eine App Ende-zu-Ende-Verschlüsselung bieten kann, benötigt sie eine zusätzliche kryptografische Schicht, die Schlüssel zwischen den an einer Konversation teilnehmenden Geräten einrichtet, so dass diese Geräte die Daten der Nutzer auf eine Weise verschlüsseln können, die Clouddienste nicht entschlüsseln können. Vor MLS gab es keine offene, interoperable Spezifikation für diese zusätzliche Ebene. MLS füllt diese Lücke und bietet ein vollständig spezifiziertes, formal verifiziertes und für Entwickler einfach zu verwendendes System.”

In dem aktuellen Protokollentwurf, der nun final angenommen wurde, heißt es, mit dem Double-Ratchet-Algorithmus des Signalprotokolls sei das Problem zum Austausch symmetrischer Schlüssel zwischen genau zwei Teilnehmern gut untersucht und inzwischen eine übliche Lösung. Gelöst werden soll mit MLS darüber hinaus aber vor allem die sichere Kommunikation in Gruppen mit teils auch Tausenden Teilnehmern. Denn die üblichen Vorgehensweisen des Schlüsselaustausches auf Basis von Double-Ratchet skalieren linear mit der Größe der Gruppen, was schnell Probleme verursacht.

Grundlage von MLS ist dabei ein Binärbaum (Ratchet Tree), mit dem geteilte Schüssel für Untergruppen oder die gesamte Gruppe erstellt werden können. Dabei werden ausgehend von den Blättern immer paarweise Schlüssel abgeleitet. Wird ein Teilnehmer aus der Gruppe entfernt und werden deshalb neue Schlüssel erzeugt, müssten so nur log(N)-Verschlüsselungsoperation durchgeführt werden, statt N-1 wie in vielen bisher genutzten Protokollen.

Zu dem Protokoll hinzu kommen klare Anweisungen, wie bei einer Änderung der Zusammensetzung der Gruppe neue Schlüssel aus den alten abgeleitet werden können oder auch welche Ciphersuites genutzt werden können sowie zahlreiche weitere Details. Aufbauend auf dem nun zur Standardisierung vorgesehenen Protokoll erstellt die zuständige IETF-Arbeitsgruppe für MLS auch noch ein Architektur-Dokument, das Hinweise zur Infrastruktur-Umsetzung in konkreten Anwendungen liefert. Hinzu kommt eine weitere Erläuterung für den Einsatz in einer föderierten Umgebung, also dem Einsatz über mehrere Messenger hinweg.

Laut IETF wird MLS bereits in Ciscos Webex und von Ring Central verwendet. Darüber hinaus planen das von AWS übernommene Wickr sowie auch Matrix auf MLS umzusteigen. Ob und wann mittels MLS aber wirklich eine weitgehende Interoperabilität von Messengern umgesetzt wird, bleibt abzuwarten. Im Herbst 2021 warnten etwa zahlreiche Betreiber davor, sie dazu zu verpflichten.

Der Beitrag Messaging Layer Security: IETF-Protokoll für sichere Gruppenchats erschien zuerst auf Linux-Magazin.

Immer wieder bereiten Antivirenprogramme Browser-Herstellern Probleme. Microsoft hat nun einen fünf Jahre alten Bug behoben, der mit Firefox auftritt.

Windows-Hersteller Microsoft hat einen etwa fünf Jahre alten Fehler behoben, der für eine ungewöhnlich hohe CPU-Last des Systems gesorgt hat, sobald der Firefox-Browser eingesetzt wurde. Das geht aus einem Eintrag im Bugtracker von Mozilla hervor. Demnach sei die Ursache für die hohe CPU-Last ein Teil der in Windows eingebauten Antivirenlösung Defender.

Schnell haben die beteiligten Entwickler als Grund für die CPU-Last von Windows Defender ein spezielles Zusammenspiel mit dem Betrieb des Firefox-Browsers vermutet. Immerhin ist die Aufgabe des Windows-Programms unter anderem, ungewöhnliche Aktivitäten von Software wie eben dem Browser zu erkennen. Dafür werden auch von dem Firefox genutzte Dienste oder geschriebene Dateien überwacht.

Nach mehreren Jahren ohne größere Ursachenforschung nahm sich schließlich ein Mozilla-Entwickler des Problems an und untersuchte das Verhalten mithilfe von Profiling-Werkzeugen unter Windows. Dabei stellte sich heraus, dass der Firefox sehr viele Aufrufe der Virtual-Protect-API der Windows-Speicherschnittstelle macht. Ist die Echtzeiterkennung von Windows Defender aktiviert, führt das wiederum zu der deutlich überhöhten CPU-Last des Kernbestandteils der Antivirenlösung.

Wie es in dem Bugeintrag von Mozilla heißt, hat Microsoft dieses Verhalten als Fehler anerkannt, inzwischen behoben und eine aktualisierte Version des Defender in der vergangenen Woche verteilt. Damit sinkt dann die CPU-Last bei der Nutzung des Firefox-Browsers. Zusätzlich dazu arbeitet Mozilla aber weiter an seinem Profiling und einer verbesserten Nutzung des Speicher-APIs von Microsoft, was insbesondere für die Nutzung der JIT-Compiler von Vorteil sein soll.

Der Beitrag Defender-Bug verursachte hohe CPU-Last bei Firefox-Nutzung erschien zuerst auf Linux-Magazin.

Das GUI-Toolkit GTK3 wird seit Jahren nicht mehr weiterentwickelt und ist in der Langzeitpflege. Das Gimp-Team schafft endlich die Portierung.

Die Portierung der freien Bildbearbeitung Gimp auf das Toolkit GTK3 für die Oberfläche ist offiziell abgeschlossen. Das berichtet der zuständige Entwickler Jehan Pagès, alias ZeMarmot, auf Twitter. Der Code dafür findet sich im Hauptentwicklungszweig des Open-Source-Projekts. Der Entwickler hat die Roadmap des Projekts entsprechend aktualisiert.

Für das Team ist die Umsetzung des Ports ein wichtiger Meilenstein, den die Beteiligten bereits im Frühjahr 2011 erstmals angekündigt hatten. Damals erschien Gnome 3.0 mit dem neuen Toolkit erstmals. Mit dem nun abgeschlossenen Umstieg auf GTK3 will das Team künftig auch Gimp 3.0 veröffentlichen. Eine Vorschau darauf ist bereits seit mehr als zwei Jahren verfügbar.

GTK3, das parallel zu Gnome im vergangenen Jahrzehnt immer weiterentwickelt wurde, befindet sich zwar bereits seit einigen Jahren in der Langzeitpflege und erhält keine neuen Funktionen. Für das Gimp-Team bedeutet die Umsetzung jedoch endlich einige wichtige Vorteile wie die vergleichsweise problemlose Unterstützung für Displays mit einer hohen Auflösung, was bisher nur mit eher schlechten Workarounds möglich war.

Darüber hinaus ist das Team dank des modernen Toolkits auch in der Lage, Wayland zu unterstützen, ohne besonders viele zusätzliche Arbeiten dafür umsetzen zu müssen. Laut der Roadmap müssen allerdings noch einige Fehler behoben werden. Wann die mit dem GTK3-Port verbundene Version Gimp 3.0 erscheint, ist derzeit aber noch nicht bekannt. Zusätzlich zu GTK3 und Wayland wechselte das Team für Gimp 3.0 auch das Build-System, stellte den Code komplett auf eine Multi-Layer-Architektur um und setzte Verbesserungen an der Farbverwaltung um.

Der Beitrag Gimp schließt GTK3-Port nach über einem Jahrzehnt ab erschien zuerst auf Linux-Magazin.

Auch wenn Security-Scanner vor ungepatchter Software warnen, sollten Windows-Systemkomponenten wie Curl nicht manipuliert werden.

Der Hauptentwickler der Download- und Transferbibliothek Curl, Daniel Stenberg, warnt in seinem Blog ausdrücklich davor, die mit Windows ausgelieferte Curl-Version zu löschen oder eigenständig zu ersetzen. Denn dies hat offenbar zur Folge, dass Windows-Upgrades nicht mehr durchgeführt werden können, weil Windows selbst eine Manipulation seines Systems erkennt und das Upgrade schließlich verweigert.

Der Vorgang und die Warnung sind unerwartet, laut Stenberg aber aktuell motiviert. Für die Erklärung der Hintergründe muss der Open-Source-Entwickler relativ weit ausholen und beginnt mit der Integration von Curl in das Windows-System. Zuvor war es lange Zeit vergleichsweise schwierig, Curl selbst für Windows zu kompilieren und dort einzusetzen. Kurz nach der Windows-Integration lieferte das Curl-Projekt selbst auch offizielle Windows-Builds aus.

Diese Art der parallelen Installationsmöglichkeiten und Entwicklungen führt nun offenbar aber zu weiteren Problemen in Bezug auf die Pflege und Sicherheitshinweise für die Software. Stenberg verweist im konkreten Fall auf einen Bug mit CVE-ID, der durch das Curl-Projekt selbst schon länger behoben ist. Microsoft behob den Fehler jedoch erst einige Monate später in seiner als Systemkomponente vertriebenen Version.

In der Zwischenzeit wurde jedoch wohl die Windows-Version von einem Security-Scanner wegen der Sicherheitslücke als gefährdet markiert. Doch statt in diesem Fall auf das Windows-Update zu warten, finden sich im Netz Empfehlungen dazu, wie die Warnung der Security-Scanner umgegangen werden kann. Diese Tipps umfassen aber die Deinstallation der Windows-Version von Curl – oder den Ersatz dieser durch eine Version der Open-Source-Version mit den eingangs beschriebenen Problemen.

Der Beitrag Gelöschte Curl-Instanz zerschießt Windows-Updates erschien zuerst auf Linux-Magazin.

Chris Lattner hat LLVM begründet und Swift erfunden. Die Sprache Mojo soll Vorteile von Python und C vereinen.

Die neue Programmiersprache Mojo soll allen KI-Programmierern eine Heimat bieten und dabei die Einfachheit von Python mit der Geschwindigkeit von C kombinieren. Das zumindest verspricht das KI-Startup Modular, das von LLVM-Gründer Chris Lattner mitbegründet worden ist und von diesem derzeit als CEO geführt wird.

Mojo baut dabei direkt auf Python auf, das als Grundlage der aktuellen KI-Forschung gilt und für zahlreiche Frameworks wie etwa Tensorflow oder Pytorch genutzt wird. Die neue Sprache soll offenbar eine Art Übermenge für Python selbst sein und den Zugriff auf das komplette Python-Ökosystem bieten. Modular zählt hier vor allem die für Berechnungen wichtigen Bibliotheken Numpy und Pandas auf.

Erreicht werden sollen die Geschwindigkeitsverbesserungen von Mojo vor allem dank einer Laufzeitumgebung, die Modular selbst erstellt, sowie der Compilertechnik MLIR. Bei dieser handelt es sich um eine neue Art der Intermediate Representation (IR), die Lattner selbst gemeinsam mit weiteren Forscher bereits vor mehr als drei Jahren vorstellte.

Statt diese Art der Compiler-Zwischenschicht je Sprache selbst zu erstellen oder auch für bestimmte Hardware zu optimieren, soll MLIR durch einen Mehrschichtansatz (Multi-Level) eben verschiedene Probleme lösen, diese aber letztlich in einem Projekt zusammenführen.

Für Mojo ergebe sich dank MLIR ein Zugriff auf die Beschleunigereinheiten von KI-Hardware. So sollen Threads ebenso genutzt werden können wie Low-Level-Funktionen, etwa Tensor-Cores oder die AMX-Erweiterungen. Bei spezifischen numerischen Berechnungen soll Mojo so bis zu 35.000-fach schneller sein als Python und damit auch schneller als üblicher C++-Code.

Noch befinde sich Mojo in der Entwicklung. Modular bietet aber eine Art Spielwiese auf Grundlage von Jupyter-Hub, um die Sprache bereits auszuprobieren. Dazu ist allerdings noch eine Anmeldung notwendig.

Der Beitrag Mojo: LLVM-Gründer will Python für KI-Anwendung aufbohren erschien zuerst auf Linux-Magazin.

Einheitlicher Firmware-Support wie auf x86-Maschinen fehlt vielen Entwicklungsboards. Ein RISC-V-Board zeigt, dass es auch anders geht.

Die Entwickler des Visionfive 2, dem ersten Single Board Computer (SBC) mit RISC-V-CPU samt 3D-Grafik, haben für die Plattform eine UEFI-Unterstützung erstellt. Die Grundlagen dafür basieren auf der Open-Source-Implementierung EDK2, das bereits seit einigen Jahren über einen Port auf RISC-V verfügt. Die meisten RISC-V-SBC verzichten bisher auf eine UEFI-Unterstützung und nutzen oft Firmware auf Grundlage von U-Boot.

Der Vorteil von UEFI ist dabei offensichtlich. Immerhin bietet dieses eine einheitliche und standardisierte Schnittstelle zur Initialisierung und Verwaltung des Systems. Auch Firmware-Updates sind dank UEFI zumindest theoretisch deutlich leichter umzusetzen. Das nutzt etwa das Open-Source-Projekt des Linux Vendor Firmware Service (LVFS) mit dem Werkzeug LVFS aus, das inzwischen auf zahlreichen Linux-Laptops und -Heim-PCs genutzt werden kann.

Das Fehlen einer einheitliche Firmware-Schnittstelle sowie auch das Fehlen von ACPI auf vielen RISC-V-SBC ebenso wie bei der Konkurrenz mit ARM-Chips erschwert die Nutzung im Vergleich zu x86-Boards enorm. Das liegt vor allem daran, dass die Linux-Distributionen zum Teil speziell auf einzelne Boards samt Hardware-Beschreibung angepasst werden müssen. Eine Unterstützung von UEFI könnte das vereinfachen.

Für Interessierte stellen die Entwickler des Visionfive 2 Anleitungen bereit, wie das UEFI auf dem SBC genutzt werden kann und wie der Code dafür auch selbst kompiliert werden kann. Alternativ dazu stehen auch von dem Team gebaute Binärdateien bereit. Das Linux-System selbst startet der Anleitung zufolge dabei als EFI-Executable. Denkbar ist, dass hier künftig auch andere Bootloader wie Grub von der UEFI-Umgebung ausgeführt werden können.

Der Beitrag RISC-V-Board Visionfive 2 bekommt UEFI-Support erschien zuerst auf Linux-Magazin.

Als letzte große Linux-Distribution will nun auch Ubuntu ein Desktop-System mit unveränderbarem Kern anbieten. Anwendungen sollen per Snap kommen.

Die von Canonical gesponserte Linux-Distribution Ubuntu könnte schon bald eine neue Variante seiner Desktop-Version anbieten, wie das Team in seinem Blog ankündigt. Demnach plant das Team, künftig die an Endnutzer gerichtete Desktop-Variante auch auf Grundlage von Ubuntu Core anzubieten. Erstmals angekündigt hatte das Team Ubuntu Core und die damit verbundenen Snap-Pakete bereits im Jahr 2014. Bisher zielte das System vor allem auf IoT- und Container-Anwendungen ab, nicht auf den Desktop. Das soll sich nun ändern.

Grundidee von Ubuntu Core ist ein unveränderbares (immutable) Basissystem, das aus den wichtigsten Kernkomponenten wie Kernel, Systemdiensten und einigen Bibliotheken besteht. Dieses System wird nur lesend genutzt und kann nicht direkt im laufenden Betrieb verändert werden. Aktualisierungen sollen nur atomar umgesetzt werden, also “alle auf einmal oder gar nicht”, wie das Team das selbst beschreibt. Zwar gibt es bei diesen Systemen meist noch klassische Pakete und eine Paketverwaltung, aber nur, um das Basissystem selbst zu erstellen, und nicht, damit dies von Endnutzer tatsächlich benutzt wird.

Die von Benutzern letztlich eingesetzte Software läuft auf diesem System dann in Containern oder in anderweitig voneinander isolierten Umgebungen. Ubuntu hat dafür das Snap-Paketformat erstellt. Doch wie das Team selbst schreibt, war dessen Einsatz für Desktop-Software mit einigen “Ecken und Kanten” verbunden. Daran habe das Team aber in der Vergangenheit kontinuierliche Verbesserungen vorgenommen und will das Konzept nun für eine vollständige Desktop-Distribution verwenden.

Ähnliche Ansätze wie die nun für Ubuntu geplante Variante verfolgen auch das von Red Hat gesponserte Fedora Silverblue sowie Suses MicroOS, dessen Community-Variante im Opensuse-Projekt ebenfalls mit Desktop ausgeliefert wird. Initiiert hat diese Art des Linux-Desktop-Systems Google mit ChromeOS, das unter anderem deshalb nicht als klassische Linux-Distribution angesehen wird. Für Ubuntu soll sich aus dem Ansatz eine größere Sicherheit und mehr Flexibilität ergeben. Die bisherige Variante der Linux-Distribution soll aber auch künftig weiter als Abbild zum Basteln und für die volle Kontrolle über das System bereitstehen.

Der Beitrag Ubuntu plant Desktop ausschließlich mit Snaps erschien zuerst auf Linux-Magazin.

ChatGPT und ähnliche KI-Bots sind auf Stackoverflow eigentlich verboten. Die Moderatoren sagen nun, sie dürften das nicht mehr durchsetzen.

Die Moderatoren und Nutzer der Code-Hilfeplattform Stackoverflow sowie damit verbundener Foren von Stackexchange haben einen Streik angekündigt. Die Beteiligten werfen dem Betreiberunternehmen der Plattformen vor, “ein nahezu vollständiges Verbot der Moderation von KI-generierten Inhalten erlassen” zu haben. Damit verweisen die Unterstützter des Streiks auf eine neue Richtlinie für die Moderatoren hin. Dabei sind KI-generierte Inhalte auf den Plattformen eigentlich verboten.

Ausgelöst wurde der Streik, weil das Unternehmen in der neuen Moderationsrichtlinie festlegt, dass die von den Moderatoren bisher getroffenen Vorannahmen nicht mehr zur Entscheidung benutzt werden dürfen. Dies umfasst etwa den Schreibstil einer Antwort oder dem generellen Verhalten eines Beitragenden, woraus die Moderatoren bisher darauf schlossen, ob die Inhalte von einer KI erstellt worden sind. Diese Vorannahmen seien aber die Grundlage für die meisten der bisher ausgesprochenen Suspendierungen von Nutzern.

Darüber hinaus sollen die Moderatoren künftig jene Programme nicht mehr benutzen dürfen, die beim Erkennen von KI-generierten Inhalten helfen sollen – sogenannte Detektoren. Aus Sicht der Moderatoren führen diese beiden neuen Regeln in Kombination dazu, dass KI-Inhalte auf der Plattform faktisch erlaubt würden, da diese nicht mehr effektiv moderiert und gelöscht werden könnten.

Dazu heißt es: “Diese Änderung hat unmittelbare schädliche Auswirkungen auf die Plattform. Viele Menschen sind der festen Überzeugung, dass die Zulassung von KI-generierten Inhalten, die als nutzergenerierte Inhalte getarnt sind, den Wert der Websites mit der Zeit auf null senken wird.” Der Streik soll nun nicht nur bezwecken, dass die neuen Regeln zurückgenommen werden. Die Moderatoren fordern außerdem eine offene Kommunikation des Betreiberunternehmens Stackexchange und eine bessere Integration der Community.

Der Beitrag ChatGPT: Stackoverflow-Moderatoren streiken im Streit um KI-Inhalte erschien zuerst auf Linux-Magazin.

Für den Nextcloud Hub 5 hat das Team die lokalen KI-Funktionen erweitert. Der Server soll sich außerdem für Verschlusssachen eignen.

Das Entwicklungsteam des freien Kollaborationsservers Nextcloud hat mit der aktuellen Version Nextcloud Hub 5 die erst vor wenigen Monaten angekündigten KI-Funktionen deutlich erweitert. Damit soll der erste “On-Premise Open Source KI-gesteuerte digitale Arbeitsplatz” geboten werden, wie es in der Ankündigung heißt. Grundlegende Idee ist, die Ansatz zum Selbsthosten der Open-Source-Software auch auf KI anzuwenden, die bisher oft nur über Clouddienste großer Konzerne nutzbar ist.

Zu den neuen KI-Funktionen gehören eine Gesichts- und Objekterkennung in Nextcloud Photos, generierte Hintergrundbilder in der Videochatkomponente Nextcloud Talk, eine Bildgenerierung mittels Stable Diffusion. Und es können komplette Transkripte von Videokonferenzen erstellt werden. Nextcloud bietet außerdem automatische Übersetzungen, einen intelligenten Posteingang für E-Mails oder einer Spracherkennung zum Diktieren von Texten. Weitere KI-Funktionen sollen im Laufe dieses Jahres folgen.

In der Ankündigung heißt es weiter: “Nextcloud Hub 5 ist bereit für den Einsatz in Bereichen, die mit offiziellen Sicherheitseinstufungen wie VS-NfD in der Deutschen Bundesregierung arbeiten.” Dafür habe das Team aktuelle Sicherheitsfunktionen eingeführt. Das Angebot speziell für Behörden, öffentliche Institutionen und große Unternehmen weitet Nextcloud mit der Unterstützung für S/Mime sowie Gemeinschaftsordnern in der Groupware-Komponente aus.

Die bereits verfügbare Outlook-Integration hat Nextcloud gemeinsam mit Sendent komplett neu entwickelt. Dazu heißt es: “Dieses Update ermöglicht die Nutzung der Outlook-Integration auf MacOS sowie in der Outlook-Web-Oberfläche”. Mithilfe eines neuen Exchange-Connectors können zusätzlich Kalender- und Kontaktdaten mit Outlook synchronisiert werden.

Der Beitrag Nextcloud will “KI-gesteuerten digitalen Arbeitsplatz” erschien zuerst auf Linux-Magazin.

Das offene OpenSIL von AMD soll einen vollständigen Ersatz für die Agesa-Firmware bieten. Es läuft schon auf einer Referenzplattform.

Chip-Hersteller AMD hat erstmals den Code seiner OpenSIL-Initiative (Open Source x86 Silicon Initialization Library) auf Github veröffentlicht. Dabei handelt es sich um ein grundlegendes Neudesign der bisher als Agesa (AMD Generic Encapsulated Software Architecture) bezeichneten Firmware. Das soll nicht nur die Sicherheit erhöhen und eine leichtere Skalierung ermöglichen, sondern auch dafür sorgen, dass moderne Systemfirmware wie Coreboot auf den AMD-Chips läuft.

Der nun verfügbare Code ist offensichtlich aus langen Vorarbeiten hervorgegangen und umfasst mehr als 500 Dateien sowie etwa 100.000 Zeilen Code und Konfigurationsanweisungen. Konkret handelt es sich um drei verschiedene Bibliotheken, die die eigentliche Initialisierung übernehmen sowie plattformspezifische Funktionen und Helferfunktionen bereitstellen. Dieser in C geschriebener Code soll direkt in die Host-Firmware der OEMs integriert werden können.

Erstellt wurde das OpenSIL-Projekt von AMD laut der Ankündigung vor etwa zwei Monaten als Kollaborationsprojekt gemeinsam mit den Coreboot-Spezialisten von 9Elements sowie dem Firmware-Entwickler AMI. Hinzu kommen die Server- und Rechenzentrumsbetreiber AWS, 3mdeb, Datacom, Google und Meta sowie das auf Integration und Skalierung spezialisierte Start-up Oxide.

Umgesetzt ist OpenSIL bisher jedoch lediglich als Machbarkeitsstudie für eine Referenzplattform von AMDs Epyc-CPUs der vierten Generation alias Genoa. Ziel ist demnach offenbar eine breit angelegte Testphase mit den beteiligten Unternehmen und weiteren interessierten Kunden. Vollständig ist das Projekt bisher aber noch nicht, so fehlt etwa die komplette Dokumentation, da AMD diese noch nicht freigegeben hat. In den produktiven Einsatz kommen soll der OpenSIL-Code aktuellen Plänen zufolge erst im Jahr 2026. Ob dies dann auch für die Consumer-CPUs der Ryzen-Serie genutzt wird oder nur für die Server-CPUs der Epyc-Serie, ist derzeit noch unklar.

Der Beitrag OpenSIL: AMDs Open-Source-Firmware erstmals verfügbar erschien zuerst auf Linux-Magazin.

Nach dem Ende des klassischen CentOS könnte es für RHEL-Nachbauten wie Rocky Linux und Alma Linux sowie deren Kunden schwierig werden.

Linux-Distributor Red Hat hat angekündigt, dass das Unternehmen künftig nicht mehr direkt öffentlichen Zugang zum Quellcode seiner Enterprise-Linux-Distribution RHEL bieten will. Das vor etwas mehr als zwei Jahren neu geschaffene CentOS Stream soll demnach “das einzige Repository für öffentliche RHEL-bezogene Quellcode-Veröffentlichungen sein”, wie es in der Ankündigung heißt.

Unter anderem, um nicht gegen das Urheberrecht der zahlreichen Copyleft-Software in RHEL zu verstoßen, soll der Quellcode für Kunden und Partner von RHEL künftig aber weiter über das Kundenportal des Unternehmens bereitstehen. Zum Problem werden könnte dies vor allem für jene Nachbauten, die kompatibel zu RHEL sein sollen und die Idee des klassischen Modells der CentOS-Distribution weiterführen wollten.

Erstmals vorgestellt hatte Red Hat CentOS Stream im Herbst 2019, Ende 2020 kündigte der Hersteller dann an, das klassische CentOS einstellen zu wollen. Das alte Entwicklungsmodell von Red Hat stellte Nutzern neue oder experimentelle Funktionen über die Community-Distribution Fedora bereit. Diese wurden im Laufe von Jahren teils stabilisiert und in Red Hat Enterprise Linux (RHEL) integriert. Aus den Quellen von RHEL wiederum entsteht die stabile Variante von CentOS als einfacher und kompatibler Nachbau. Das soll vor allem Admins eine notwendige Stabilität für ihre Systeme garantieren.

CentOS Stream ist dagegen eine neue Art Rolling-Release-Variante der Distribution, die auf die Bedürfnisse von Entwicklern ausgerichtet sein soll. Entwickler bräuchten schlicht einen schnelleren Zugriff auf neue Werkzeuge und eine stärkere Kooperation mit der Partner-Community rund um RHEL, sagte der Hersteller. CentOS Stream soll dies mit ständigen Neuveröffentlichungen bieten. CentOS Stream dient dabei als eine Art Upstream für die nächste RHEL-Version, mit einer Vorschau auf neue Kernel-Versionen und neue Funktionen.

Zu der Verfügbarkeit des Quellcodes heißt es in Bezug auf das neue CentOS-Modell: “Vor CentOS Stream hat Red Hat die öffentlichen Quellen für RHEL auf git.centos.org veröffentlicht. Als sich das CentOS-Projekt auf CentOS Stream konzentrierte, behielten wir diese Repositories bei, obwohl CentOS Linux nicht mehr als RHEL-Downstream entwickelt wurde.” Für Red Hat sei die Pflege eines zweiten, separaten Repositorys nicht mehr effizient, so dass das Vorgehen beendet wird.

Doch nicht alle vorherigen CentOS-Nutzer sind zufrieden mit der Entwicklung rund um CentOS Stream, so dass sich etwa mit Alma Linux und Rocky Linux schnell Community-Weiterführungen fanden, die das Modell des binärkompatiblen Nachbaus aufrechterhalten wollen. Wie und ob dies nun ohne direkten Zugang zu dem Quellcode möglich sein wird, ist derzeit völlig unklar. Das betrifft auch große Kunden wie etwa die NASA.

Sowohl Alma Linux als auch Rocky Linux versuchen derzeit, ihre Community und Kunden zu beschwichtigen und bitten um Geduld in Bezug auf Informationen zum weiteren Vorgehen. Die Rocky Enterprise Software Foundation schreibt zudem, dass der Schritt von Red Hat immer als Möglichkeit in Erwägung gezogen worden sei.

Der Beitrag Centos Stream: Red Hat schränkt Verfügbarkeit von Quellcode massiv ein erschien zuerst auf Linux-Magazin.

Mehr als 1000 Entwickler schreiben inzwischen bei Google Rust-Code. Der Umstieg erfolgt offenbar schneller und einfacher als erwartet.

Das Open-Source-Team von Google hat die Ergebnisse einer Auswertung zur internen Nutzung der Programmiersprache Rust veröffentlicht. Grundlage dafür sind die Antworten von mehr als 1.000 Angestellten, die im vergangenen Jahr 2022 Rust-Code selbst geschrieben oder eingepflegt haben. Dabei räumt das Team auch mit einigen Gerüchten auf, die im Zusammenhang mit dem Wechsel auf Rust immer wieder genannt werden. Dazu gehört auch, dass es lange dauere, Rust zu erlernen. Google widerspricht hier deutlich.

Demnach fühlten sich zwei Drittel der befragten Entwickler schon nach nur maximal zwei Monaten sicher genug, zu einer bestehenden Codebasis in Rust beizutragen. Darüber hinaus heißt es, dass die Hälfte der Befragten nach nur vier Monaten genauso produktiv in Rust arbeiten könne wie in einer anderen Sprache. Laut Google entsprechen diese Zahlen auch dem Zeitraum zum Erlernen anderer Sprachen, sowohl “innerhalb als auch außerhalb von Google.”

Google schreibt: “Insgesamt haben wir keine Daten gesehen, die darauf hindeuten, dass Rust im Vergleich zu anderen Sprachen, die diese Entwickler zuvor bei Google verwendet haben, einen Produktivitätsnachteil mit sich bringt.” Von Vorteil für die Nutzung von Rust sind dabei laut der Auswertung auch die als “besonders hilfreich” bezeichneten Fehlermeldungen. Ebenso sei ein Großteil der Befragten zufrieden mit der eigenen Codequalität in Rust, wobei 85 Prozent der Entwickler davon ausgehen, dass ihr Code in Rust zu einer höheren Rate korrekt ist als in anderen Programmiersprachen.

Die größten Probleme beim Rust-Umstieg seien die als zu langsam beschriebene Geschwindigkeit des Rust-Compilers sowie die Makros, das Ownership-System und die Async-Programmierung. Google zieht aus der Umfrage folgenden Schluss: “Wenn Rust nicht nur besser für das Schreiben von qualitativ hochwertigem Code ist, sondern auch besser dafür geeignet ist, diesen Code schneller einzupflegen, dann ist das für Unternehmen, die die Einführung von Rust evaluieren und in Betracht ziehen, eine ziemlich überzeugende Reihe von Gründen, die über Leistung und Speichersicherheit hinausgehen.”

Der Beitrag Google-Entwickler wechseln schnell auf Rust erschien zuerst auf Linux-Magazin.

Für Nutzer von Pocket soll der Login damit sicherer werden. Für Mozilla vereinfacht sich damit aber wohl vor allem die Technikpflege.

Sämtliche Nutzer des Später-lesen-Dienstes Pocket sollen ab dem 15. August nur noch Firefox-Accounts zum Anmelden nutzen können. Das kündigt der Betreiber Mozilla in einem Blogeintrag an. Der Wechsel des Diensteanbieters zur Authentifizierung dient laut Mozilla unter anderem dazu, weitere zusätzliche Sicherheitsmaßnahmen wie eine Zwei-Faktor-Authentifizierung (2FA) anbieten zu können.

Mit Pocket können Texte aus dem Web oder aus Apps zum späteren Lesen gespeichert werden. Das Start-up wurde bereits vor mehr als sechs Jahren von Browser-Hersteller Mozilla übernommen. Der Dienst ist standardmäßiger Teil des Firefox-Browsers und wird etwa genutzt, um Browsernutzern Nachrichten und Empfehlungen in der Übersicht eines neuen Tabs anzuzeigen. Für Mozilla selbst dient Pocket dabei als möglicher Weg, eine alternative Einkommensquelle zu schaffen und dadurch weniger abhängig von Verträgen mit Suchmaschinenanbietern zu sein.

Der Firefox-Account selbst bietet zahlreiche Funktionen, die die Nutzung des Browsers bequemer machen sollen. Dazu gehört etwa eine Synchronisation von Lesezeichen oder Passwörtern über mehrere Geräte hinweg. Ebenso kann der Account für den Firefox-Monitor genutzt werden, womit über gehackte Passwörter und Zugangsdaten informiert wird. Darüber hinaus nutzt Mozilla den Firefox-Account aber auch für seine anderen kommerziellen Aktivitäten, die sich an Endkunden richten, wie das VPN, Firefox Relay oder MDN Plus. Die Integration von Pocket führt dies nun also zusammen.

Ab kommendem 11. Juli sollen Pocket-Nutzer über den Wechsel informiert werden. Der von Mozilla als Upgrade beschriebene Prozess umfasst die Erstellung eines neuen Firefox-Accounts, falls dieser noch nicht existiert. Für jene, die eine Apple ID oder ein Google-Konto zum Login für Pocket nutzen, soll die Umstellung auf den Firefox-Account automatisch geschehen.

Der Beitrag Mozilla erzwingt Firefox-Accounts für Pocket-Nutzer erschien zuerst auf Linux-Magazin.

An dem Linux-Dateisystem Bcachefs wird seit acht Jahren gearbeitet. Die Fronten sind so angespannt, dass selbst Linus Torvalds zur Ruhe aufruft.

Linux-Chefentwickler Linus Torvalds hat den ersten Release Candidate für die kommende Version 6.5 des Kernels veröffentlicht. Darin allerdings nicht enthalten ist der Code für das moderne Dateisystem Bcachefs, wie Torvalds selbst in der Ankündigung hervorhebt. Als Grund dafür gibt er eine sehr lange Diskussion der Kernel-Entwickler an, an der sich Torvalds überraschenderweise nicht selbst beteiligte. In der Release-Ankündigung ruft er allerdings explizit zur Beruhigung auf.

Tatsächlich ist die Diskussion auf der Mailingliste sehr hitzig und teils persönlich, was angesichts der positiven Veränderungen im Umgang der Community untereinander im Laufe der vergangenen Jahre durchaus ungewöhnlich ist. Hinzu kommt, dass an Bcachefs seit inzwischen etwa acht Jahren entwickelt wird, das Dateisystem selbst auch ohne offizielle Integration in den Linux-Kernel inzwischen zahlreiche Nutzer hat und die verschiedenen Funktionen laut dem Hauptentwickler Kent Overstreet als stabil angesehen werden.

Auslöser der wiederkehrenden Diskussionen rund um die Aufnahme und Umsetzung von Bcachefs ist dabei nicht der Code für das Dateisystem selbst, sondern die von Overstreet dafür angedachten Änderungen an anderen Teilen des Kernels oder Interaktionen mit anderen Subsystemen. Für derartige Änderungen braucht es üblicherweise die Zustimmung der dafür zuständigen Betreuer. Diese fühlen sich aber von Overstreet zum Teil komplett übergangen oder ignoriert.

Die Geduld zahlreicher Beteiligter, weiter mit Overstreet zu diskutieren und ihn von technischen Lösungen zu überzeugen oder schlicht auf mögliche Probleme hinzuweisen, scheint dabei inzwischen größtenteils erschöpft. Der Entwickler Christian Brauner schreibt dazu etwa: “Und es scheint so, als gäbe es keine Möglichkeit, dies in Ruhe zu regeln, sondern als sei stattdessen massives defensives Zurückdrängen erforderlich”. Der für seine zahlreichen Änderungen am Linux-Kernel bekannte Christoph Hellwig lehnt die Aufnahme außerdem direkt ab, weil die Patches weder von den betroffenen Maintainern akzeptiert worden seien und sich wohl auch niemand außer Overstreet selbst finde, der sich für den Code verbürgen könne.

Auch wenn Torvalds sich nicht direkt an der öffentlichen Diskussion beteiligt, zeigt die Nichtaufnahme des Codes, dass er diese aufmerksam verfolgt. Wie und ob sich der Aufruf zur Beruhigung von Torvalds künftig auswirkt, bleibt abzuwarten. Eine zügige Aufnahme von Bcachefs in den Linux-Kernel erscheint derweil ungewiss.

Der Beitrag Kernel-Community zerlegt sich bei Diskussion um Dateisystem erschien zuerst auf Linux-Magazin.

Eine neue Ansicht für E-Mails, den Kalender, das Adressbuch, eine einheitliche Werkzeugleiste und mehr soll die neue Thunderbird-UI bieten.

Das Entwicklungsteam des freien E-Mail-Clients Thunderbird hat die Version 115 seines freien E-Mail-Clients veröffentlicht. Damit veröffentlichen die Beteiligten erstmals die grundlegenden Arbeiten an der neuen grafischen Oberfläche der Anwendung, die unter dem Codenamen Supernova erstellt wird. Erstmals vorgestellt hatte die Pläne dazu der für die Produkt- und Geschäftsentwicklung zuständige Ryan Sipes bereits vor mehr als drei Jahren.

Völlig neu gestalteten die Verantwortlichen dabei die typisch dreigeteilte Ansicht mit Ordnern, der Nachrichtenliste sowie der eigentlichen Anzeige der E-Mails. Statt wie bisher standardmäßig üblich die einzelnen Nachrichten unter der Liste der neuen E-Mails anzuzeigen, werden diese nun als dritte Spalte neben der Nachrichtenleiste dargestellt.

Die Nachrichtenleiste selbst ist dafür deutlich kompakter gestaltet worden und nutzt jetzt eine Kartenansicht, die an moderne Webmail-Clients erinnern soll. Dazu gehört die Unterstützung von Textdarstellungen über mehrere Zeilen hinweg. Die Ordner-Ansicht ermöglicht es nun, lokale Ordner wahlweise nicht anzuzeigen. Auch sollen sich die Ordner einfach verschieben und so besser sortieren lassen. Die Ordner-Ansicht zeigt außerdem die vergebenen Tags und bietet so einen schnellen Zugriff auf entsprechend markierte E-Mails.

Neu an der Thunderbird-Oberfläche ist darüber hinaus eine vereinheitlichte Werkzeugleiste am obereren Rand des Fensters. Die dargestellten Optionen sollen sich dabei an den Kontext des gerade geöffneten Teils der Anwendung anpassen können. Die Werkzeugleiste und das Layout lassen sich aber weiterhin anders konfigurieren. Zudem passte das Team das Adressbuch sowie die Kalenderansicht optisch an. Zahlreiche weitere Änderungen listen die Release Notes.

Der Beitrag Thunderbird 115 bringt neue Oberfläche erschien zuerst auf Linux-Magazin.

Mit Stack Canarys sollen eigentlich Buffer-Overflows erkannt werden. Durch Zufall entdeckte ein Team von Meta, dass das nicht immer der Fall ist.

Der Chip-Designer ARM und das Team der GNU Compiler Collection (GCC) haben eine Sicherheitslücke (CVE-2023-4039) im gleichnamigen C-Compiler der Softwaresuite behoben. Der zugrunde liegende Fehler findet sich im Stack Smashing Protector von GCC für ARM64, der mit Hilfe eines sogenannten Canarys das Ausnutzen eines Stack Buffer Overflows verhindern soll und wurde offenbar durch Zufall entdeckt.

Das berichten Tom Hebb von Metas Sicherheitsgruppe Red Team X sowie die auf den ARM-Befehlssatz spezialisierte Sicherheitsexpertin Maria Markstedter alias Azeria. Aufgefallen war die Sicherheitslücke demnach in einer Demo-Anwendung bei einem Exploit-Training, das Markstedter anbietet. Dabei werden unter anderem verschiedene Techniken zum Ausnutzen von Sicherheitslücken auf ARM-Plattformen besprochen.

Die betroffene GCC-Funktion setzt einen sogenannten Canary in die Datenstrukur im Speicher. Bei einem Buffer Overflow wird der Canary überschrieben, was wiederum erkannt werden kann, um den Programmablauf zu unterbrechen. Ein Angriff, der solch einen Overflow ausnutzt, um den Programmablauf zu kapern, kann so verhindert werden. Der Name der Technik ist dabei als Analog zum Canary in a coal mine gewählt.

Für Datentypen mit dynamischer Speichergröße wie etwa Variable-Length-Array (VLA) oder Objekte, die per Alloca-Aufruf erstellt werden, funktionierte der Schutz über den Canary bisher aber nicht wie vorgesehen und konnte umgangen werden. Davon betroffen ist aber nur die ARM64-Plattform und keine der anderen unterstützen CPU-Architekturen. Hebb führt dies in der Beschreibung der Lücke auf eine Eigenart dieser Implementierung zurück. Ähnliche Lücken fanden sich bereits in der GCC-Umsetzung für ARM32 sowie im Clang-Compiler für ARM64.

Der Beitrag GCC: Forscher finden Sicherheitslücke bei Exploit-Training erschien zuerst auf Linux-Magazin.

Die KI-Forschungsgruppe Laion hat das freie Llama-Modell für Deutsch angepasst. Das soll vor allem die englischsprachige Dominanz brechen.

Zahlreiche große Sprachemodelle (LLMs) wie etwa GPT-4 oder das intern von Google eingesetzte Palm sind zwar mehrsprachig, offene und frei verfügbare Sprachmodelle sind in den allermeisten Fällen jedoch ausschließlich in Englisch verfügbar. Die in Deutschland initiierte offene KI-Forschungsgruppe Laion setzt dem mit LeoLM (Linguistically Enhanced Open Language Model) nun ein deutschsprachiges Modell entgegen.

Das Modell basiert auf dem frei verfügbaren Llama-2-Modell und ist derzeit mit 7 oder 13 Milliarden Parametern nutzbar. Diese Größen dürften sich dank einiger Optimierungen dafür eignen, auch auf heimischen Rechnern und Grafikkarten ausgeführt zu werden, statt ausschließlich im Rechenzentrum. Darüber hinaus heißt es in der Ankündigung, dass ein Modell mit 70 Milliarden Parametern bereits in Arbeit sei. Trainiert wird das Modell mit Unterstützung von HessianAI, einem Forschungsverbund mehrerer hessischer Universitäten, und dessen Supercomputer 42, der mehr als 600 Nvidia A100 Karten nutzt.

Als Grund für die Arbeiten nennen die Beteiligten, dass die Qualität von Llama 2 inzwischen zwar an kommerzielle und proprietäre Modelle heranreiche. Da das Training dafür aber hauptsächlich mit englischsprachigen Daten durchgeführt worden sei, enthalte das Modell zahlreiche Verzerrungen, die etwa auf die US-Kultur oder die Sprache selbst zurückzuführen seien. “Wir versuchen, diese Probleme in der Fallstudie für deutsche Sprache zu lindern, indem wir viele der modernen Techniken anwenden, um ein wirklich fähiges, lokalisiertes und zweisprachiges LLM zu entwickeln”, schreibt Laion dazu.

Das Team passt Llama für Deutsch mit einer zweiten sogenannten Pre-Training-Phase an. Dabei wird das bestehende Llama-Modell auf Grundlage eines weiteren deutschen Text-Korpus weiter trainiert. Dazu wird Oscar genutzt. Zum Überprüfen der Ergebnisse des so trainierten Modells haben die Beteiligten darüber hinaus bisher nur in Englisch verfügbare Benchmarks ins Deutsche übersetzt. Wie zu erwarten liefert LeoLM dabei dann auf Deutsch leicht bessere Ergebnisse, schneidet aber auf Englisch leicht schlechter ab als Llama 2. Dabei seien die Vorteile durch die Verbesserungen für Deutsch aber deutlich wichtiger als die leichten Verschlechterungen für Englisch, was zeige, dass auch bereits gelernte Inhalte mit der genutzten Vorgehensweise erhalten bleiben können.

Der Beitrag Laion: Riesiges Sprachmodell für Deutsch trainiert erschien zuerst auf Linux-Magazin.

Die Linux-Community startet einen zweiten Versuch, das alte Microsoft-Protokoll RNDIS zu entfernen. Beim ersten Mal gab es zahlreiche Diskussionen.

Neuer Versuch, neues Glück ist offenbar die Devise von Linux-Kernel-Entwickler Greg Kroah-Hartman, der nun erneut anstrebt, das veraltete und von Sicherheitsrisiken geplagte RNDIS-Protokoll aus dem Linux-Kernel zu entfernen.

Bereits im vergangenen Jahr startete der Entwickler eine Diskussion um diesen Schritt und setzte die Änderung zunächst vorläufig auch im Code um. Kroah-Hartman musste diese aber zurücknehmen, da es zahlreiche Einsprüche gegen die Änderung gab. Das wohl größte Problem ist, dass RNDIS für viele Nutzer die wichtigste Komponente ist, um ihren Rechner per Tethering über ein Android-Smartphone mit dem Internet zu verbinden. Darüber hinaus nutzen auch Geräte wie Router weiterhin RNDIS für ihre Netzwerkverbindungen.

Die von Microsoft initiierte Remote Network Driver Interface Specification stammt aus den Zeiten von Windows XP und dient als proprietäres Protokoll, das fast ausschließlich zusammen mit USB genutzt wird. Dazu wird eine Art virtuelle Netzwerkverbindung erzeugt, die wiederum nah an die Windows-Schnittstelle für Netzwerktreiber (NDIS) angelehnt ist.

Das grundlegende Konzept von RNDIS ist darüber hinaus laut Kroah-Hartman, der unter anderem den USB-Zweig in Linux verantwortet, nicht nur unsicher und angreifbar, sondern vor allem auch nicht absicherbar. Außerdem gibt es im USB-Protokoll selbst mehrere offene und standardkonforme Alternativen zu RNDIS.

Ob sich allerdings an der Problematik in Bezug auf das Tethering seit der ersten Diskussion etwas änderte und warum Kroah-Hartman diesen neuen Versuch zum Entfernen von RNDIS unternimmt, ist derzeit noch nicht klar. So bleibt abzuwarten, ob der Patch tatsächlich in den Hauptzweig des Linux-Kernels wandern wird.

Der Beitrag Linux-Entwickler wollen RNDIS erneut rauswerfen erschien zuerst auf Linux-Magazin.

Eine Lücke in Curl wäre laut dem Hauptentwickler mit einer sicheren Sprache vermeidbar gewesen. Der Weg dahin ist aber äußerst schwierig.

Der Hauptentwickler des Open-Source-Werkzeugs Curl, Daniel Stenberg, hat die aktuelle Version 8.4.0 veröffentlicht und dabei eine mehrere Jahre alte Sicherheitslücke (CVE-2023-38545) behoben. Laut Stenberg handelte es sich um die gravierendste Lücke in Curl seit Jahren.

Die Ursache ist ein Heap-Buffer-Overflow im Ablauf eines Socks5-Proxy-Handshakes. In seinem Blog beschreibt Stenberg, wie es zu dem Fehler kam, und geht dabei auch auf die fehlende Speichersicherheit von C ein, in dem Curl programmiert ist.

Der Entwickler, der das Projekt seit 1996 leitet und als profilierter C-Programmierer gilt, schrieb dazu: “Wenn man den Code jetzt liest, ist es unmöglich, den Fehler nicht zu sehen. Ja, es tut wirklich weh, die Tatsache akzeptieren zu müssen, dass ich diesen Fehler gemacht habe, ohne es zu merken, und dass der Fehler dann 1.315 Tage lang unentdeckt im Code blieb. Ich bitte um Entschuldigung. Ich bin auch nur ein Mensch.”

Weiter erklärte Stenberg, dass die Lücke wohl auch mit besseren Tests hätte entdeckt werden können. Aber schon jetzt nutze das Projekt zahlreiche Werkzeuge zur statischen Analyse und die Lücke sei dabei nicht aufgefallen. Wie der Entwickler aber ebenfalls selbst schrieb, hätte diese Art Lücke durch die Wahl einer Programmiersprache mit Speichersicherheit verhindert werden können.

Curl auf eine andere Sprache zu portieren, könne das Projekt, das fast ausschließlich von Stenberg selbst vorangetrieben wird, nicht leisten. Jedoch sollten mehr Abhängigkeiten mit einer speichersicheren Sprache genutzt werden, erklärte der Entwickler. Künftig könnten auch stückweise Teile von Curl ersetzt werden, wie dies mit Hyper geschehe.

Dabei handelt es sich um eine in Rust geschriebene HTTP-Bibliothek, die Curl als Backend nutzen kann. Diese Veränderungen geschähen derzeit aber nur sehr langsam und zeigten mit schmerzhafter Klarheit die damit verbundenen Probleme, so Stenberg.

Der Beitrag Curl-Entwickler entschuldigt sich für Speicherfehler erschien zuerst auf Linux-Magazin.

Mit KDE Connect lassen sich Smartphone und Laptop miteinander verbinden. Play Protect entfernt die App, wenn diese über F-Droid installiert wurde.

Die Android-App KDE Connect wird derzeit durch die Sicherheitstechnik Play Protect von Google automatisch von zahlreichen Smartphones entfernt. Das geht unter anderem aus Berichten auf X, vormals Twitter, oder auch einer Diskussion auf Reddit hervor. Auch in der Golem-Redaktion ist die App auf einem Pixel 6a mit aktuellem Android 14 durch Play Protect gelöscht worden.

Der KDE-Entwickler Niccolò Venerandi schreibt dazu vor einigen Tagen: “Es ist offiziell: Google deinstalliert wahllos KDE Connect von den Telefonen der Nutzer, ohne dass es dafür eine Erklärung gibt.” Inzwischen zeigt sich aber, dass dies nicht wirklich wahllos geschieht, sondern wohl nur jene Installation betrifft, die über den alternativen Open-Source-Store F-Droid bezogen werden. Das zumindest schreibt der Betreuer von KDE Connect, Albert Vaca Cintora. Die über den Play Store vertriebene App, welche aus dem exakt gleichen Quellcode erstellt wird, ist von den Löschungen wohl nicht betroffen.

In der Benachrichtigung von Play Protect zu der automatisierten Löschung heißt es, dass dies aus Sicherheitsgründen geschehe und es sich bei der App um eine Fälschung handele. Die App könne demnach personenbezogene Daten wie Bankinformationen oder Passwörter stehlen. Wie die Systeme Googles zu dieser Einschätzung kommen, ist derzeit nicht klar. Vaca kritisiert zudem, dass es für Entwickler wie ihn keine Möglichkeit gebe, das zugrunde liegende Problem einer automatischen Einordnung mit einem Menschen bei Google zu besprechen, um eine Lösung dafür zu finden. Der Entwickler fragt sich außerdem, ob dieses Verhalten im Einklang mit europäischem Wettbewerbsrecht stehe.

Die App selbst bietet in Zusammenarbeit mit einem Desktop-Client, der auch für Gnome, Windows oder MacOS bereitsteht, eine Verbindung des Smartphones mit einem Rechner. So können darüber die Zwischenablage geteilt werden, Dateien übertragen werden oder die Benachrichtigungen synchronisiert werden. Auch eine Mediensteuerung ist möglich oder die Nutzung des Smartphones als virtuelles Eingabegerät für den Laptop etwa zur Steuerung für Präsentationen oder als externes Touchpad.

Der Beitrag Google entfernt KDE-App aus F-Droid von Android-Smartphones erschien zuerst auf Linux-Magazin.

Zu alt, kaum oder falsch genutzt und ein großes Sicherheitsrisiko, schreiben die Chrome-Entwickler über den wohl ersten freien Videocodec fürs Web.

Googles Chrome-Entwicklungsteam hat angekündigt, die Unterstützung für den freien Videocodec Theora aus dem Browser entfernen zu wollen. Sollte diese Idee umgesetzt werden, wäre es das Ende des wohl ersten freien und breit verfügbaren Videocodecs für das Web. Das Chrome-Team nennt als Grund für das Entfernen des Codecs die wachsende Gefahr durch Sicherheitslücken im Zusammenhang mit Theora.

Das bezieht sich wohl vor allem auf die prinzipielle Beobachtung, dass nicht nur Zero-Day-Angriffe immer häufiger werden, sondern diese oft speziell Lücken in Mediencodecs ausnutzen. Weiter heißt es zur Begründung: “Theoras geringe (und inzwischen oft falsche) Nutzung rechtfertigt für die meisten Benutzer nicht mehr die Unterstützung. (…) Die Nutzung ist unter ein messbares Niveau im UKM gefallen. Die Websites, die wir manuell überprüft haben, bevor die Werte abfielen, bevorzugten fälschlicherweise Theora gegenüber moderneren Codecs wie VP9.”

Die Geschichte von Theora reicht dabei sehr weit zurück. Bereits vor mehr als 20 Jahren entschied sich das Unternehmen On2 Technologies, gemeinsam mit der Xiph-Foundation den Codec VP3 als offenes Theora weiterzuentwickeln. Breit durchsetzen, vor allem bei kommerziellen Anbietern, konnte sich Theora aber nie. Das zeigte sich etwa an der Diskussion um die Standardisierung des Videoelements in HTML5. Viele Unternehmen bevorzugten weiter H.264.

Erst einige Jahre später übernahm Google On2, legte den Codec VP8 offen und entwickelte kurz darauf VP9. Doch auch VP9 konnte sich außerhalb einiger prominenter Anwendungen wie Youtube oder Netflix in der Breite kaum durchsetzen. Mit dem freien Videocodec AV1, der auch als Nachfolger von VP9 gilt, ändert sich dies nun wohl aber. Eine Notwendigkeit für den Theora-Support im Browser gibt es damit schon lange nicht mehr.

In Safari oder Chrome für Android wurde der Codec nie unterstützt und laut Google erwägt auch Mozilla, den Theora-Support im Firefox zu entfernen. Der aktuelle Plan sieht vor, Theora bis Februar 2024 komplett aus Chrome zu entfernen. Support für den Codec steht danach wohl aber noch über eine Javascript-Bibliothek bereit.

Der Beitrag Freier Videocodec: Chrome will Theora entfernen erschien zuerst auf Linux-Magazin.

Das Python-Team hat festgelegt, wie die Sprache eine bessere Nebenläufigkeit bekommen soll. Bei zu großen Problemen wird dies aber nie umgesetzt.

Das technische Leitungsgremium der Sprache Python hat wichtige Details zur Umsetzung einer besseren Nebenläufigkeit bekannt gegeben. Konkret handelt es sich dabei um die Annahme und Ausgestaltung der Spracherweiterung PEP 703, die den sogenannten Global Interpreter Lock (GIL) in der Standardimplementierung CPython optional machen möchte. Das so entstehende free-threaded Python könnte aber massive Auswirkungen auf das gesamte Ökosystem haben, sodass die Beteiligten nun eben eine lange Testphase anstreben.

Begonnen werden könnte damit wohl sofort, wie es in der Ankündigung heißt. Die Technik soll dabei durch eine Option beim Kompilieren von CPython selbst aktiviert werden können. Das sollte zwar nirgendwo standardmäßig oder gar produktiv genutzt werden, ermögliche aber Paketbetreuern, die Implementierung zu testen. Eine zweite Testphase soll darüber hinaus erst starten, wenn die Arbeiten an API und ABI sich weitgehend beruhigt haben und der Community-Support für die neue Technik groß genug ist.

Letztlich soll das free-threaded Python der Standard für Sprachen werden und diese dann eben komplett ohne GIL auskommen. Das Team zielt dabei darauf, diesen Übergang so störungsfrei wie möglich zu machen. Anfänglich soll der GIL dabei noch optional verfügbar bleiben. Wenn dieser aber nicht mehr weitläufig genutzt wird, soll die Technik komplett entfernt werden.

Wie das Team selbst schreibt, sind diese Pläne derzeit noch bewusst vage gehalten und erfordern wohl dauerhaft begleitenden Diskussionen der Beteiligten. Einen Zeitplan für die Umsetzung gibt es damit noch nicht und die Verantwortlichen wollen jeden der Schritte einzeln evaluieren, auch um eventuelle Änderungen noch rechtzeitig zurücknehmen zu können. Das Python-Team behält sich dabei auch vor, sämtliche der Arbeiten an einem No-GIL-Python zurückzunehmen, sollte diese nicht die Erfolge bringen, die sich die Beteiligten wünschen.

Der Beitrag Weg für Python ohne Global Interpreter Lock frei erschien zuerst auf Linux-Magazin.

Das Team von OpenBSD will den Syscall-Aufruf komplett aus seinem System entfernen. Das soll Exploits deutlich erschweren.

Das auf Sicherheit fokussierte Open-Source-Betriebssystem OpenBSD möchte den Systemaufruf Syscall komplett aus dem eigenen Kernel und der Standard-C-Bibliothek entfernen. Das kündigt der Begründer und Leiter von OpenBSD, Theo de Raadt, auf der Mailingliste des Projekts an und verschickt dazu auch passende Änderungsdateien. Ziel dieser tiefgreifenden Änderung ist, wie es bei dem Projekt zu erwarten ist, die Sicherheit zu erhöhen.

Mit Hilfe des Syscall-Aufrufs können die anderen Systemaufrufe des Betriebssystems indirekt über eine Zahl aufgerufen werden, die die entsprechende Assembler-Sprache der genutzten Plattform unterstützen muss. Dafür gibt es Tabellen, welche etwa im Fall von OpenBSD bis zur Gründung des Projekts zurückreichen. Die Idee des Syscall-Aufrufs ist dabei noch deutlich älter und stammt dabei aus dem originalen BSD von Anfang der 80er Jahre, ist seitdem aber auch von anderen unixartigen Systemen implementiert worden. In der Linux-Dokumentation etwa heißt es, der Aufruf sei sinnvoll für den Fall, falls der gewünschte Systemaufruf über keine eigene Wrapper-Funktion in der C-Bibliothek verfüge.

De Raadt begründet den Schritt mit dem Ziel, möglichst viele Aktionen unterbinden zu wollen, die bei der Ausnutzung einer Sicherheitslücke zum Ausführen von Code führen können. Er schreibt weiter: “Mir ist klar, dass wir niemals alle [von den Angreifern] verwendeten Mechanismen vollständig beseitigen können. Ich hoffe jedoch, dass ich die Programmierer von Angriffen dazu zwinge, immer kompliziertere Methoden zu verwenden. Gleichzeitig bedeutet dies, dass weniger Methoden verfügbar sind. Andere Methoden machen die Ausnutzung anfälliger. Dies drückt die Erfolgsquoten in den ‘statistischen Niedrigprozentbereich’.”

Weiter heißt es, der Entwickler versuche dabei zuerst, die einfachen Methoden zu entfernen und Angreifer eben zu immer komplexeren Aufgaben zu zwingen. In Zukunft sollen auch die komplexeren Aufgaben zum Ausnutzen von Sicherheitslücken unterbunden werden. Sollte die Änderung für den Syscall-Aufruf wie geplant umgesetzt werden, muss sich das Team zunächst aber um die damit verbundenen Auswirkungen auf andere Software kümmern. So müssen viele Programme angepasst werden, die den Aufruf bisher benutzt haben. Das gelte insbesondere für das Go-Ökosystem, schreibt de Raadt.

Der Beitrag OpenBSD will indirekte Systemaufrufe unterbinden erschien zuerst auf Linux-Magazin.

Der Befehlssatz RISC-V soll in Android vollständig unterstützt werden. Noch in diesem Jahr soll der Support für Entwickler finalisiert werden.

Erst vor wenigen Wochen hat Google angekündigt, gemeinsam mit Qualcomm Android-Geräte auf Grundlage des freien CPU-Befehlssatzes RISC-V vertreiben zu wollen. Nun veröffentlicht Google zahlreiche Details und vor allem einen groben Zeitplan dafür, wie andere OEMs und eventuell betroffene Anwendungsentwickler auf RISC-V wechseln können. Wichtigstes Ziel laut Google ist es dabei, seinen Partnern den bereits prinzipiell vorhandenen Support möglichst ausgereift zur Verfügung stellen zu können.

So verweist Google etwa direkt auf die Patches, die es ermöglichen, Android für RISC-V-CPUs zu bauen. Diese seien aber noch nicht optimiert. Das gelte insbesondere für das Backend der Android Runtime (ART), die zum Ausführen von Apps genutzt wird. Ebenso fehlten sowohl Android selbst als auch externen Abhängigkeiten wie Compilern noch eine Erweiterung, um optimierten und platzsparenden Code zu erzeugen. Dennoch sei jetzt schon die Zeit für Experimente und eine tiefere Zusammenarbeit gekommen, versichert Google.

Noch in diesem Jahr will das Team außerdem die Arbeiten an der Binärschnittstelle des NDK abschließen und erste Testbuilds bereitstellen, um RISC-V-Android-Apps auf x86- und ARM-Hostmaschinen emulieren zu können. Anfang 2024 sollen die Emulatoren allgemein verfügbar sein, um Apps mit allen Android-Funktionen und für alle Gerätekategorie testen zu können.

Schon jetzt lässt sich Android für RISC-V in der Virtualisierungslösung des Projekts, Cuttlefish, nutzen. Fest steht ebenso, dass konkret das Befehlssatzprofil RVA22 samt Vektor- und Vektor-Krypto-Erweiterungen für Android genutzt werden soll. Google arbeitet eigenen Angaben zufolge außerdem weiter aktiv an den zahlreichen Werkzeugen zur RISC-V-Unterstützung und dem gesamten Softwareökosystem. Letzteres wird vor allem in dem Rise-Projekt mit zahlreichen Partnern aus der Hard- und Softwarebranche umgesetzt.

Der Beitrag Plan für Android-Port auf RISC-V steht erschien zuerst auf Linux-Magazin.