Mozilla hat gestern eine Ankündigung für den Firefox gemacht: Sie führen dort Nutzungsbedingungen ein. Ein Open-Source-Browser, der bislang ganz gut ohne damit auskam, setzt jetzt auf das, was sonst eher in den AGB-Friedhöfen großer Plattformen vor sich hin verstaubt. Grundsätzlich lässt sich das noch mit einem wohlwollenden Achselzucken abtun: Natürlich braucht Mozilla sicherlich eine rechtliche Grundlage für all die interaktiven Dienste, die der moderne Browser so mit sich bringt. Soweit, so juristisch.

Aber das Timing? Es hätte suboptimaler nicht sein können. Fast zeitlich wurden nämlich jene Passagen von der Webseite entfernt, die bisher versprachen, die Nutzerdaten nicht zu verkaufen. Von der Community gab es daraufhin überwiegende kritische Reaktionen wie hier, hier, hier oder hier. Auch einer der zwischenzeitlich ausgeschiednenen Gründer von Mozilla sieht das Verhalten skeptisch.

Besonders kritisch wird dieser Absatz hervorgehoben:

When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information to help you navigate, experience, and interact with online content as you indicate with your use of Firefox.

Es stellt sich die Frage, warum ein Webbrowser überhaupt Nutzungsbedingungen braucht, wenn man als Nutzer doch schon den bestehenden Lizenzbedingungen zustimmen muss. In der Abfolge der Ereignisse der letzten Jahre lässt sich aber ein Trend erkennen, dass Mozilla sich von der Nutzerschaft in meinen Augen immer weiter entfernt.

Ein Blick in die Zahlen

Schauen wir uns hierzu einmal die Zahlen und Fakten an, um einen Überblick zu bekommen.

• Der Marktanteil von Mozilla Firefox betrug nach Statcounter global im Jahr 2024 2,54%, während Chrome 67,08%, Safari 17,95% und Edge 5,2% ausmachen.
• In Deutschland sieht das alles etwas anders aus: Historisch ist der Firefox hier sehr beliebt und kommt 2024 auf stolze 9,91% hinter Safari mit 20,4% und Chrome mit 51,83%.
• Entwickelt und vertrieben wird der Firefox von der Mozilla Foundation sowie der Tochtergesellschaft Mozilla Corporation. Nach dem Finanzbericht 2023 der Foundation stammen gut 75% der Einnahmen aus sog. Royalities, die auch die Suchmaschinenpartnerschaften wie bei den berühmten Google-Deal umfassen. Für die Softwareentwicklung wurden 260 Mio. US-Dollar ausgegeben.

Firefox hat eine entscheidende Rolle für das Internetökosystem. Je mehr Googles eigene Browserplattform Chromium verbreitet ist, desto eher sind Internetstandards in Gefahr, da ohne Konkurrenz eine Spezifikation eines Standards überflüssig ist. Chromium wäre dann die Definition des Browserstandards. Google als potentiell eingestufter Monopolist wiederum kann mit der Finanzierung von Mozilla nachweisen, dass sie auch andere Browser unterstützen und gleichzeitig seinen eigenen Suchmaschinenstand manifestieren.

In genau diese Finanzierung kamen aber die letzten Jahre immer weitere Risse, nicht zuletzt durch die Kartellurteile gegen Google. Mozilla versucht schon seit Jahren, sich auf eigene Beine zu stellen, um nicht auf Google angewiesen zu sein. Umgesetzt wird dies durch Abonnements rund um den Browser, die ein stetiges Einkommen generieren sollen. Die Zahlen zeigen aber, dass die Einkünfte mit knapp 65 Mio. US-Dollar im Jahr 2023 gerade mal 10% der Gesamteinnahmen ausmachen und geradezu winzig gegenüber den ziemlich genau 4x höheren Entwicklungskosten aussehen.

Aber es ist doch alles Open Source?

Mozilla hat in den letzten Jahren darüber hinaus sein Engagement im Bereich künstlicher Intelligenz erhöht. Auch das mag die Sorge nähren, dass die zukünftig großzügig eingeräumten Berechtigungen dafür sorgen könnten, dass übertragene Daten für das eigene Training von Modellen oder den Verkauf von Trainingsdaten dienen könnten, um neue Finanzquellen zu erschließen. Ob die Sorgen berechtigt sind, wird sich in den nächsten Jahren zeigen.

An dieser Stelle mag man sich zwei Fragen stellen:

1. Warum ist die Entwicklung eines Browsers so unfassbar teuer?
2. Wie kann ein Open-Source-Browser so weit auf den kommerziellen Pfad rücken?

Ja, es überrascht, aber Browser und ihre Engines, also die Komponenten, die die Inhalte grafisch darstellbar machen, sind unfassbar komplexe Softwareprojekte geworden. Es ist heutzutage mitunter einfacher, ein einfaches Betriebssystem zu entwickeln als einen Webbrowser, der alle verschiedenen HTML- und CSS-Standards in allen Kompatibilitätsstufen beherrscht, eine Laufzeitumgebung für JavaScript besitzt und das auch performant umsetzt.

Lustigerweise war es gerade die Veröffentlichung von V8 im Google Chrome, die Anfang der 2010er-Jahre eine Wettbewerbssituation ausgelöst hat, JavaScript performant zu interpretieren, bis es auf einmal sogar im Backend eingesetzt werden konnte. Firefox wurde in der Zeit mit Vorhaben wie TraceMonkey deutlich performanter und konnte darüber hinaus viele Speicherlecks lösen.

Das ist auch der Grund, warum es so schwierig ist, einen Browser zu forken: Für die gesamte Codebase ist man auf einmal selber zuständig. Man muss sich also nicht nur darin einarbeiten, sondern gleichzeitig auf mehreren Fronten für die Sicherheit und Standardkonformität kämpfen, weil ein Browser so viele Technologien in sich vereint.

Ein Browser besteht somit aus einer einfach austauschbaren Oberfläche sowie einer Engine, die die Inhalte verarbeitet und zu einer grafisch darstellbaren Webseite verwandelt. Im Falle von Firefox war es bisher Gecko (neuerdings wohl auch Quantum genannt) und bei Google Chrome ist es Chromium. Anpassungen und Forks von Chromium wie Microsoft Edge oder Brave, die die Oberfläche anpassen, haben einen deutlich einfacheren Job als ein Projekt wie Firefox, das eine komplette Engine entwickeln muss. Aber genau diese Vielfalt an Engines schafft einen gesunden Wettbewerb.

Dieses Know-how wird auf einmal zum Asset und kann monetarisiert werden. Denn während die Open-Source-Engine lokal arbeitet, kann die Oberfläche immer mehr mit den eigenen Diensten verwoben werden – die wiederum eine Nutzungsbedingung erfordern. Diesen Weg ist Android sehr erfolgreich mit den Google-Diensten gegangen. Eine übliche Android-App greift einerseits auf Bibliotheken aus dem Android-Kern als auf Google-Mehrwertdienste zurück und kann somit nicht ohne die Google Play Store Services ausgeführt werden, die zum Vertrieb von den Smartphoneherstellern eine umfangreiche und strikte Zertifizierung abfordern. Schließt man diese Services ersatzlos aus, wird es mittlerweile überraschend ruhig bei Android.

Der Browser als Politikum

Der Browser als das Tor in das Internet ist mittlerweile auch in das politische Visier geraten. Zuletzt wurden in den EU-Rechtsakten rund um "eIDAS 2.0" (Verordnung (EU) 2024/1183) im Artikel 45a Browser in einer kritischen Komponente reguliert. Die EU fordert dort ein, dass Browser sich staatlichen Zertifizierungsstellen beugen müssen und diese nicht ausschließen dürfen. Zertifizierungsstellen (CAs) bestätigen die Identität von Webservern und können im schlimmsten Fall genutzt werden, um sich fälschlich als eine fremde Seite auszuweisen und sich so in die Verbindungen einzuklinken. Bisher wird die Liste zulässiger CAs in einer selbstverwalteten Branchenvereinigung namens CA/Browser-Forum gelöst, nun erzwingen sich Staaten einen Zugang.

Die Browserhersteller sind somit in ihrer Wahl der Sicherheitsfunktionen regulatorisch eingeschränkt. Erst nach öffentlichem Druck u.a. von Mozilla kam die EU leicht entgegen und erlaubt jetzt den temporären Ausschluss von Zertifizierungsstellen, wenn es begründete Sicherheitsbedenken gibt.

Auch in dieser Hinsicht steigen die Markteintrittsbarrieren neuer Webbrowser, wenn sie zusätzlich neben der Entwicklung noch juristische Fragen beantworten müssen.

Quo vadis?

Ich bin seit über 15 Jahren überwiegend treuer Firefox-Nutzer und schätze auch neuere Funktionalitäten wie den eingebauten PDF-Reader PDF.js. Der Einbindung der Online-Dienste zum scheinbaren Selbstzweck, insbesondere auch mit "KI-Funktionen", stehe ich aber kritisch gegenüber – und teile meine Meinung in der Frage mit vielen Nutzern.

Gleichzeitig muss man aber auch wissen, dass es nahezu unmöglich ist, ein hochkomplexes Softwareprojekt in der Entwicklung zu finanzieren, wenn es nicht gerade eine kommerzielle Verwertung genießt. Zwei bekannte Ausnahmen von dieser Regel sind:

• der Linux-Kernel, der als Infrastrukturtechnologie durch die Komponentenhersteller, Softwareunternehmen und Cloud-Anbieter finanziert wird, sowie
• das Firefox-Projekt, das im Wesentlichen vom Google-Deal lebt.

Hier haben also kommerzielle Unternehmen einen Vorteil vom Projekt und können das Geld umlegen und als "Abfallprodukt" ein Produkt für die Allgemeinheit schaffen.

Wenn Firefox allerdings finanziell neu organisiert werden muss, gibt es drei Optionen:

• entweder muss das Projekt die Infrastrukturtechnologie auf irgendeine Weise kommerzialisieren oder
• es findet sich ein Industriekonsortium, das einen solchen Vorteil aus der Existenz von Firefox zieht, dass es die Kosten schultert oder
• Fonds und Förderprojekte wie der OTF in den USA oder STF in Deutschland finanzieren das Projekt strategisch aus der öffentlichen Hand.

Entscheidend ist, dass die Wettbewerbssituation und die Datenhoheit von Webbrowsern nicht nur taktisch, sondern strategisch für das Fortkommen identifiziert werden.

Mobilfunk ist eine unverzichtbare Technologie unseres Alltags – und gleichzeitig ein faszinierendes Beispiel für moderne Funksysteme. Während wir bei WLAN als Endnutzer oft sowohl das Endgerät als auch die Basisstation, den sogenannten Access Point, betreiben, ist der Mobilfunk weitaus komplexer und auch fachlich schwieriger zugänglich. Die Mobilfunknetze werden von großen Telekommunikationsunternehmen im lizenzierten Spektrum betrieben, und selbst auf unseren Telefonen bleibt die Interaktion mit dem Mobilfunknetz minimal. Meist reicht es, die SIM-Karte einzulegen, und schon funktioniert alles. Was viele nicht wissen: Auch Betriebssysteme wie Android oder iOS kommunizieren nicht direkt mit dem Mobilfunknetz. Diese Aufgabe übernimmt ein spezieller Chip, der sogenannte Baseband-Prozessor.

Open Source und Mobilfunk: Das Osmocom-Projekt

In der Open-Source-Welt gibt es nur wenige Projekte, die diese Funktechnologie zugänglich machen. Eines herausragendes Beispiel ist das Osmocom-Projekt. Schon ein erster Blick auf die Übersicht zeigt, dass es nicht "die eine" Mobilfunksoftware gibt. Vielmehr müssen viele verschiedene Komponenten ineinandergreifen und wie in einem Orchester zusammenspielen, um ein funktionierendes Netz bereitzustellen.

Sicherheitsforschung im Mobilfunk

Der Blick auf die Sicherheit sollte im Mobilfunk nicht vernachlässigt werden. So mag es überraschen, dass ältere GSM-Mobiltelefone deutlich unsicherer sind, als moderne Geräte, die auf LTE und 5G basieren. Hintergrund sind die verbesserten kryptographischen Verfahren.

Im Risikozone-Podcast haben wir uns in der Episode 65 mit der Mobilfunksicherheit genauer beschäftigt. Wir sprechen mit Adrian Dabrowski und Gabriel Gegenhuber über ihre Forschungsarbeiten und geben gemeinsam Einblick in eine Technologie, die als selbstverständlich wahrgenommen wird, aber in der Arbeitsweise völlig anders herangeht, als wir es aus der IETF-Welt mit TCP/IP & Co. gewöhnt sind.

Zusätzlich stellen Gabriel und Adrian das Open-Source-Projekt MobileAtlas vor. Dieses Projekt, inspiriert vom RIPE Atlas, widmet sich der Vermessung der Mobilfunkqualität und schafft eine interessante Plattform für weitere Analysen und Forschungsarbeiten.

Die 90-minütige Episode ist auf der Podcastseite oder direkt unter diesem Artikel abrufbar.

Das Jahr 2024 geht zu Ende und ich möchte die Gelegenheit nutzen, mich herzlich bei allen Lesern zu bedanken, die in diesem Jahr meinen Blog verfolgt, meine Artikel gelesen oder ihn durch Kommentare und Zuschriften bereichert haben.

Zu Beginn des Jahres bin ich zum Institut für sichere mobile Kommunikation (ISMK) gewechselt und habe den Podcast Risikozone mitgenommen, sodass ich die Episoden nun im Rahmen meiner Tätigkeit dort produziere. Viele IT-Sicherheitsthemen, die ich im Blog veröffentlicht hätte, fließen nun zwei Mal im Monat in die Episoden dort ein. Über das vergangene Jahr des Podcasts haben wir in Episode 63 gesprochen.

Mein Blog begleitet mich nun schon seit 2016. Im neunten Jahr seines Bestehens habe ich mit 14 Artikeln den Schnitt der vergangenen Jahre gehalten. Wie gewohnt möchte ich zum Jahresende auf einige Highlights und bedeutende Themen des vergangenen Jahres im Blog zurückblicken.

Rückblick auf 2024

Eines der herausragendsten Ereignisse in der IT-Sicherheits- und Open-Source-Welt war zweifellos die xz-Lücke. Über diese Backdoor habe ich sowohl hier im Blog als auch in den Risikozone-Episoden 45 und 46 berichtet.

Ein weiteres bemerkenswertes Sicherheitsproblem war die OpenSSH-Sicherheitslücke RegreSSHion. Zudem wurden in der glibc zwei Lücken entdeckt, deren besondere Bedeutung in ihrem Alter lag: Die verwundbaren Versionen wurden seit 1992 ausgeliefert.

Beim Durchsehen des Blogarchivs fiel mir zudem auf, dass die Veröffentlichung von KDE Plasma 6 ebenfalls in dieses Jahr fiel. Die neue Version der Desktopumgebung, die erstmals nun auf Qt 6 aufbaut, fühlt sich schon so vertraut an, dass es schwer zu glauben ist, dass sie erst 2024 erschienen ist.

Pläne für 2025

Das Thema Künstliche Intelligenz, insbesondere im Bereich der Large Language Models (LLMs), hat sich 2024 stabilisiert. Nach dem anfänglichen Hype zeichnet sich nun eine Phase der Konsolidierung ab. Für das kommende Jahr plane ich, die LLM Timeline wieder zu aktualisieren, um die Entwicklungen der letzten Monate zu dokumentieren.

Auch technisch wird sich auf dem Blog einiges tun. Ich arbeite an einer Erweiterung der Blogsoftware, um die Unterstützung für mehrere Sprachen zu verbessern und das Design speziell für Infografiken zu optimieren.

Guten Rutsch

Ich wünsche euch allen einen guten Rutsch in das Jahr 2025 und freue mich darauf, euch auch im neuen Jahr mit spannenden Artikeln, Podcast-Episoden und technischen Updates begleiten zu dürfen! Danke für eure Unterstützung und euer Interesse!

In der letzten Episode des Risikozone-Podcasts habe ich ganz kurz das Thema der verkürzten Hashwerte und auftretenden Kollisionen angesprochen. Jetzt gibt es ein Proof of Concept zu der Thematik.

Worum es geht

Ein kurzer Refresher, worum es in der Thematik überhaupt geht: Als Git entwickelt wurde, musste ein Weg gefunden werden, wie man die Referenzen auf Commits, die Dateien und die Dateibäume realisiert. In vielen Systemen wie z. B. Issue-Trackern werden aufsteigende Indizes verwendet. In einem verteilten System wie Git ist das aus verschiedenen Gründen der Synchronisation nicht so einfach möglich, da sonst Kollisionen, also gleiche IDs für unterschiedliche Objekte entstehen könnten. Eine Alternative wäre UUIDs, da die IDs einen randomisierten Anteil haben und die Wahrscheinlichkeit für Kollisionen gesenkt wird.

Noch besser als UUIDs ist allerdings Content-adressable Storage, bei dem Inhalte einzig durch ihren Inhalt adressiert werden. Das ist so, als würde man den gesamten Inhalt der Datei nochmal in den Dateinamen schreiben. Der Clou dabei ist jedoch, dass der gesamten Dateiinhalt gar nicht in den Dateinamen geschrieben werden muss, um die Datei durch ihren Inhalt identifizierbar zu machen.

Mit kryptographischen Hashfunktionen wie SHA-1 oder SHA-256 existiert ein Mittel, um einen beliebig langen Dateiinhalt zu einem immer gleich langen Wert, dem Hash, umzuwandeln. Dabei sind kryptographische Hashfunktionen so konstruiert, dass die Wahrscheinlichkeit für Kollisionen durch verschiedene Mechanismen stark minimiert wird. Ein SHA-1-Hash für den Dateiinhalt "Hallo Welt" wäre z. B. 28cbbc72d6a52617a7abbfff6756d04bbad0106a. Ein netter Nebeneffekt ist, dass Dateien mit gleichem Inhalt im Content-adressable Storage auch nur einmal abgespeichert werden, wodurch sogar Deduplikation ermöglicht wird.

Git nutzt dieses Verfahren, um die eingechekten Dateien abzuspeichern. Diese Dateien werden dann in Trees zusammengebunden und in Commits mit den jeweiligen Vorgänger-Commits (parents) in einem sog. Merkle-Tree verheiratet.

Commits werden somit auch durch einen SHA-1-Hash identifiziert, der im hexadezimalen Format 40 Zeichen lang ist.

Das Problem

Das Problem bei dem Verfahren liegt jetzt darin, dass dieser Hash üblicherweise noch weiter abgekürzt wird, um ihn benutzerfreundlicher in Oberflächen oder E-Mails darzustellen. Damit wird natürlich die Wahrscheinlichkeit für Kollisionen erhöht.

Habe ich einen Hash 28cbbc72d6a52617a7abbfff6756d04bbad0106a und nutze nur 28cbbc zur Referenz, reicht das in den meisten kleinen Repositories aus, um einen Commit eindeutig zu referenzieren. In großen Repositories mit vielen Dateien und Commits kann es auf einmal passieren, dass ein weiterer Commit 28cbbcc00aa8ef4e80596c16ecfdb4bc92656cd3 auftaucht, sodass 28cbbc nicht mehr eindeutig einen Commit beschreibt.

Um das Risiko zu verringern, sollte die Mindestanzahl der Zeichen für einen abgekürzten Commit erhöht werden.

Das Kernel-Repository

Genau darum geht es in der aktuellen Diskussion. Aktuell nutzen die Linux-Entwickler zur Referenz von Commits in ihren E-Mails 12 Zeichen lange Hashes. Die Diskussion dreht sich um die Frage, ob die Zahl weiter erhöht werden sollte. Linus Torvalds ist bisher dagegen, weil er das Risiko für Kollisionen gering sieht und er die Position vertritt, dass ein Commit immer mit dem Commit Message Title angegeben werden sollte, was ungewollte Kollisionen ausreichend verhindere.

Gestern veröffentlichte Kees Cook einen Blogpost, indem er eine Commit-Kollision mit dem Werkzeug lucky-commit bewusst herbeiführte, um darauf aufmerksam zu machen, dass die Git- und Kernel-Entwicklungstools mit solchen Situationen klarkommen sollten. Es ist unwahrscheinlich, dass solche Kollisionen bei 12 Zeichen versehentlich entstehen, aber ein Angreifer könnte dies ausnutzen.

Dies sollte ein Apell an alle Entwickler sein, deren Tooling auf abgekürzte Commit-Hashes setzt. Schauen wir mal, wie sich das weiterentwickelt.

Ein Kommentar zu SHA-1

Abschließend ein Kommentar noch zu SHA-1. Wie viele von euch wissen, ist SHA-1 selbst nicht mehr vertretbar kollisionssicher. Das bedeutet, es kann passieren, dass auf einmal zwei Dateiinhalte sich doch den gleichen Hash teilen könnten, wenn ein Angreifer es drauf anlegt.

Da dies natürlich Git massiv stören könnte, gibt es schon Bestrebungen, das Verfahren auf SHA-2 zu aktualisieren, wodurch sich die Hashlänge auch vergrößert. Das ist aber gar nicht so einfach, da SHA-1 an vielen Stellen in die Struktur eines Git-Repos hartkodiert wurde.

Hier geht es aber nicht um das unsichere SHA-1. Durch die Abkürzung des Hashes von 40 auf 12 Zeichen wird die Kollisionssicherheit bewusst und massiv zugunsten der Benutzerfreundlichkeit geschwächt. Und das erfordert immer eine regelmäßige Evaluation, welches Niveau noch vertretbar ist.

Am heutigen 30. November jährt sich die Veröffentlichung von ChatGPT zum zweiten Mal. Die zwei Jahre fühlen sich wie vier an, wenn man bedenkt, was alles passiert ist. Blicken wir auf einige Entwicklungen zurück.

ChatGPT hat die Forschung im Bereich der künstlichen Intelligenz (KI) auf den Kopf gestellt. KI wurde in der Öffentlichkeit bis 2022 mit verschiedenen Teilbereichen wahrgenommen, z. B. Spamfilterung, Bilderkennung, Texterkennung, Klassifikation von Bildern und Texten oder Vorhersagen. Generative Modelle waren eine Nische und vielen eher durch Anwendung des Deepfakes bekannt, bei denen es darum geht, (bewegte) Bilder so gut wie möglich hochrealistisich zu approximieren und nach Belieben anzupassen.

Veränderte Forschungslandschaft

Mittlerweile könnte man annehmen, dass in der Öffentlichkeit KI, ML und LLM synonym betrachtet werden (was zum Glück nicht so gilt). Über diese Vereinfachung könnte man sich jetzt aufregen, sollte es aber differenziert betrachten. Einerseits lernen viel mehr Menschen KI kennen als vorher. Wenn diese Anwender auch nur eine der Technologien, sei es LLM, einsetzen, ist es gewissermaßen eine Bereicherung. Andererseits versuchen viele, bestehende Verfahren und Technologien auf LLMs anzuwenden. Zum Beispiel kann eine Klassifikation (z. B. Spam oder nicht Spam?) entweder mit einem spezialisierten Modell (z. B. Bayes) durchgeführt werden – oder ChatGPT kann einfach nach der Einordnung gefragt werden. Dieser Einsatz ist kritischer zu hinterfragen, weil Nebeneffekte wie Halluzinationen bisher zuverlässige Aufgaben verwässern: wenn ein Klassifikator mit der Softmax-Funktion zwischen 4 Kategorien entscheiden soll, kann er sich nur für eine Kategorie entscheiden. LLMs hingegeben können mit einer neuen Kategorie antworten.

An dieser Stelle sollte erwähnt werden, was ChatGPT eigentlich ist: Es war, ist und bleibt wohl vorerst eine aufgepumpte Textvervollständigungsmaschine. Dabei können die Modelle zum jetzigen Forschungsstand weder das Gesagte konzeptionalisieren, noch einen inneren Sinn anwenden. Die Modelle wurden darauf trainiert, kohärente Texte für Eingaben auszugeben. So kann eine Anfrage wie "Was ist 2+2?" sicherlich durch Training mit 4 beantwortet werden. Das Modell ist jedoch an sich nicht in der Lage, beliebige Rechenaufgaben mit der Präzision eines Taschenrechners zu beantworten.

Das Spannende ist aber der Zusatz "an sich", den ich der Vollständigkeit halber erwähnen muss. Denn die Forscher und Entwickler haben begonnen, diese Schwäche mit Tricks zu kompensieren. Beim Toolformer-Ansatz wird das LLM darauf optimiert, anstatt einer direkten Antwort einen Funktionsaufruf an der passenden Stelle möglichst syntaktisch korrekt auszugeben, z. B. Das Ergebnis von 2+2 ist [Calculator(2+2)]. Die LLM-Ausgabe kann dann anschließend einem Interpreter übergeben werden, der für vorgegebene Funktionen deterministisch korrekt die Berechnung durchführt und das Ergebnis an der Stelle einfügt.

Es lässt sich erahnen, dass LLMs mittlerweile mehr als das reine Modell sind. Die Ausgaben werden technisch durch gezielte Fragestellung, das Prompt Engineering, in eine bestimmte Richtung gelenkt und anschließend angereichert. Diese Schritte können beliebig oft wiederholt werden. Baut man dieses Verfahren so aus, dass in der Antwort bestimmte Aktionen benannt werden, auf die dann wieder Eingaben folgen, kann man Agenten bauen. Das ist ein jahrzenhntealter Ansatz, der jetzt wieder in Mode kommt.

Dieses Ökosystem ist umfangreich und wächst immer weiter. Nur, weil ich ein Large Language Model habe, habe ich noch kein funktionierenden ChatGPT-Klon. Vielmehr gilt es, operative und technische Herausforderungen im Backend zu lösen (Stichwort GPUs und Clustering) und das Modell in eine Pipeline einzubetten. Das Training allein reicht somit nicht mehr aus – bildet aber auch keine Voraussetzung mehr, wie wir später sehen.

Grundsätzlich ist es gut, wenn mehr Aufmerksamkeit der Erforschung künstlicher Intelligenz und maschinellem Lernen gewidmet wird. Die durch die hohen Trainingskosten notwendig gewordene Kommerzialisierung zur Finanzierung hat allerdings auch umfangreiche Auswirkungen gehabt. Die Start-up-Welt verschob sich nicht nur von Blockchain, Metaversum und Fintech hin zu AI, sondern wurde getrieben vom Ziel, das beste Modell zu trainieren. Rückblickend ein Himmelfahrtskommando, wenn man sieht, wie schnell neue Modelle veröffentlicht wurden und wie gering der Return-on-Invest ausfallen kann.

Das Jahr 2023 fühlte sich an, als würde jedes KI-Labor eines jeden größeren Konzerns die Zwischenergebnisse seiner LLM-Leute veröffentlichen. Jede Woche gab es neue Papers, die nicht mehr in jährlichen begutachteten Konferenzen, sondern als Preprint auf arXiv veröffentlicht wurden. LLMs gibt es schon seit über 5 Jahren, aber die Zuverlässigkeit und verbundene Aufmerksamkeit wurde erst mit dem Durchbruch von InstructGPT ermöglicht, was die Basis von ChatGPT in der ersten Version bildete. In 2023 habe ich aktiv eine LLM-Timeline gepflegt und es wurde deutlich, dass "jeder" es einmal versuchen wollte, Beispiel BloombergGPT. Jeder einzelne Beitrag war dabei wertvoll, es war jedoch schwer, den Überblick zu behalten.

Der Gewinner: Open Source

Der Gewinner der letzten zwei Jahre war jedoch nicht nur OpenAI, das letztes Jahr um diese Zeit mit Machtkämpfen (wired.com) beschäftigt war. Vielmehr hat mit Meta (Facebook) ein Unternehmen das Ruder an sich gerissen, von dem man es am wenigsten erwartet hätte, und einen Beitrag geleistet, den man sich noch weniger hätte vorstellen können. Der zeitlich passende Shift von Metaverse zu AI war die Überraschung der letzten Jahre, wie man auch im Aktienkurs sehen konnte.

Die Problematik war, dass die bereits erwähnte Kommerzialisierung zu proprietären Modellen geführt hat, bei denen weder die Gewichte als Basisdaten veröffentlicht noch die Mitbenutzung erlaubt wurde. Durch das aufwändige Training und die hohe Anpassungsfähigkeit an neue Aufgaben hatte auf einmal das Modell an sich einen Wert. Davor war es entweder die Methodik, wie man ein solches Modell trainiert und einsetzt (das - und nur das - ist im Übrigen in der Regel auch nur wissenschaftlich publikationfähig) oder der Datensatz selber, auf dem trainiert wurde. Das Modell konnte man sich früher einfach selber erzeugen und so die Experimente reproduzieren.

Meta AI war nun einer der ersten großen Anbieter, die mit LLaMA im Februar 2023 ein Modell aufwändig trainiert und dann zum Download freigegeben haben. Das geschah allerdings noch unter einer recht restriktiven Lizenz und mit persönlicher Voranmeldung, war aber eines der ersten Modelle, das an die Leistung von OpenAI im entferntesten herankam. Interessanterweise war es auch die ausbleibende Klagewelle, die zur Verbreitung und Weiterentwicklung der Modelle führte, die rechtlich mindestens in einem Graubereich geschah und fast schon an die Einführung der Kartoffel in Deutschland erinnerte.

Spätere Versionen wie Llama 3 wurden unter freizuzügigeren Lizenzen veröffentlicht. Bei diesen lässt sich streiten, ob man sie als Open Source bezeichnen kann. Fest steht, dass für den Einsatz somit Modelle bereitstehen, an denen man lokal testen und sie ggfs. auf eigene Trainingsdaten anpassen kann. Bei der Bilderkennung wurde hierbei üblicherweise der Begriff Transfer Learning verwendet, bei LLMs wurde das Verfahren als Finetuning bekannt. Somit war auch die Bezeichnung von Foundation Models geboren, die die Basis für Finetuning bilden.

Aus Europa stammt ein zwischenzeitlich ähnlich leistungsstarkes Modell mit dem Namen Mistral, das mit der Apache-2.0-Lizenz auch eine echte, anerkannte Open-Source-Lizenz trägt. Der Trend geht somit Richtung Open Source. Zieht man die Parallele zu den Betriebssystemen mit Windows und Linux, ist es schon sehr überraschend, dass in einer solchen Massentechnologie mit technsichen und finanziellen Hürden tatsächlich so schnell der Gedanke der Open-Source-Kultur keimt.

Gesellschaft und Regulierung

Eine weitere Parallele ist die gesellschaftliche Akzeptanz. Diese ist verglichen mit dem Jahr 2000 überraschend hoch. Während Wikipedia als Konkurrenz zur gedruckten Enzyklopädie zu meiner Schulzeit mindestens verachtet wurde, ist ChatGPT als Alternative zur eigenen Arbeitsleistung überraschend salonfähig. Es gilt vielmehr ein "Es geht nicht weg, wir müssen damit klarkommen!" als ein "Wir müssen es unbedingt bekämpfen!".

Bleibt zum Schluss noch der Blick auf die Regulierung. Die Veröffentlichung von ChatGPT kam in dieser Hinsicht zu einem ungünstigen Zeitpunkt. Die Europäische Kommission hat sich in den vergangenen Jahren vorgenommen, den Einsatz in bestimmten Bereichen der künstlichen Intelligenz im Hinblick auf z. B. Scoring-Systemen für Kredite oder Gesichtserkennung zu regulieren. Also typische Einsatzbereiche, die man sich zu der Zeit vorstellte. Ein erster Gesetzesentwurf wurde Anfang 2021, also ein halbes Jahr vor ChatGPT, vorgelegt. Mit ChatGPT kam dann in dem Gesetzgebungsverfahren so richtig Fahrt auf, sodass einerseits die Gegner von KI-Systemen mit einem großen Verbotshebel in der Verhandlung antraten, die Befürworter die Verordnung nicht aus den Augen verloren und die Investitionsträger von KI-Start-ups ihre wirtschaftliche Position bewahren wollten. Das Ergebnis war, dass Foundation Modelle in die Verordnung aufgenommen wurden, aber ab einer Grenze, die scheinbar ihren geistigen Ursprung interessanterweise in der einer zeitgleich entwickelten Executive Order 14110 des US-Präsidenten Joe Biden hat. Zwischenzeitlich ging es darüber hinaus um die strikte Regulierung jeglicher statistischer Methoden. Dies wurde glücklicherweise aber noch abgeschwächt.

Mittlerweile ist der AI Act von der EU in Kraft. So unnötig ich die Regulierung zu einem solch frühen Zeitpunkt halte, so halte ich die Ausnahme großer Teile der Forschung von der Regulierung als wichtige Errungenschaft. Dass man heute aber für Dinge kämpfen muss, die gestern noch selbstverständlich wären (Forschungsfreiheit), ist auch ein Zeichen gesellschaftlicher Umwälzungen.

Interessanterweise gibt es aber mit der TDM-Schranke auch EU-Voragben, die im in dieser Thematik nicht zu unterschätzenden Urheberrecht dem Training von LLMs zuträglich sein können. Ob und inwiefern diese Schranke für Wissenschaft und Wirtschaft anwendbar ist, wird aktuell durch Gerichtsverfahren und Gutachten geklärt.

Fazit

Ich nutze ChatGPT regelmäßig und sehr gerne und finde daher die Veröffentlichung vor zwei Jahren einen wichtigen Meilenstein, zumal es sehr gut bei Übersetzung oder Grammatikoptimierung hilft (dieser Text ist aber menschengeschrieben). Tatsächlich habe ich knapp ein Jahr vorher schon begonnen, mit GPT-3 zu arbeiten, weil es zu der Zeit schon recht populär war, aber noch viel manuelle Arbeit für gute Ergebnisse erforderte. Mit ChatGPT hat sich die Zugänglichkeit und Qualität von LLMs deutlich vereinfacht, weswegen ich den kometenhaften Aufstieg des Produktes gerechtfertigt sehe.

2023 befand sich allerdings die gesamte Techindustrie regelrecht in einem Wahnzustand. Die anfangs hohen Erwartungen, die in die Werkzeuge gesteckt wurden, konnten teilweise erfüllt werden. Wie hoch die Erwartungen allerdings tatsächlich waren, zeigt sich erst, wenn die Investments realisiert werden.

LLMs sind der Hammer, mit dem jedes Problem wie ein Nagel aussieht. Für die Zukunft wünsche ich mir mehr Differenzierung, da es mehr als LLMs in der KI-Welt gibt. Dabei blicke ich gespannt auf die Robotik, weil sich hier ein weiterer großer Anwendungszweck der KI befindet, der auf seinen Durchbruch wartet. Schauen wir, was uns die nächsten Jahre bringen.

Kurz notiert: In den letzten Tagen kursierte ein Artikel von Geoff Huston von der APNIC durchs Netz, in dem er das Ziel in Frage stellt, IPv4 langfristig durch IPv6 zu ersetzen. Warum es obsolet ist? Weil es DNS, NAT und SNI gäbe. Heißes Thema, ich weiß.

Drei Gedanken hierzu:

(1) Transition. Ja, hier hat IPv6 ziemlich versagt und das war schon ziemlich früh absehbar, siehe The IPv6 mess von djb. Ich muss eine Station komplett für IPv6 und IPv4 konfigurieren, damit in der Übergangsphase die Erreichbarkeit sichergestellt ist. Das ist das Gegenteil, wie viele Protokolle agiert haben, die sich gut migrieren lassen. Bei abwärtskompatiblen Protokollen sieht das Protokoll für nicht migrierte Teilnehmer wie das alte Protokoll aus und neue Teilnehmer können anderweitig die neue Version erkennen und besondere Features nutzen. Hätte man besser machen können, aber ich vermute, dass die IPv6-Autoren auch mit einer unkomplizierten Migration gerechnet haben. Und eines ist auch klar: Wenn man ein Protokoll neu und ordentlich entwirft, kann man auch endlich alte Zöpfe abschneiden.

(2) Internet gleichberechtiger Teilnehmer. Einer der großen Durchbrüche beim TCP/ICP-basierten Internet, so wie wir es heute kennen, ist, dass technologisch nicht zwischen Konsument und Produzent unterschieden wird. Jeder Teilnehmer kann einen eigenen Server aufspannen und möglichst weltweit seine Dienste anbieten. NAT (vor allem, wenn man es selber nicht verwalten kann) verhindert das Prinzip und schafft ein klares Gefälle, weil hinter dem NAT liegende Stationen nicht mehr frei agieren können.

(3) IPv4-Adresshandel. Die Knappheit der IPv4-Adressen hat einen Markt geschaffen, wo /24er-Blöcke für zehntausende an Euros gehandelt werden. Wir reden hier – um bei einer Analogie zu bleiben – von reinen Nummerschildern. Diese künstliche Verknappung schafft eine weitere Einstiegshürde für neue, ggfs. Teilnehmer und friert in Folge nur den heutigen Status Quo ein.

Fazit: Eigentlich ist die IPv6-Migration auf einem guten Weg. IPv6-only sollte auch das Ziel in meinen Augen sein. Jetzt auf dem (vermutlich erst halben) Weg abzubrechen, würde ich aber sehr kritisch sehen, weil es nur denen in die Hände spielen würde, die sowieso nach alter TK-Manier eine Unterteilung in Konsumenten und Produzenten sehen wollen. Aber jeder der großen Big-Tech-Konzerne auch mal als kleiner Teilnehmer an den Start gegangen. Die Schaffung höherer Einstiegshürden ist zwar in so einem Markt natürlich, aber nichts, was man gutheißen sollte. Freier Zugang für das Internet ist für die Innovationsfähigkeit umso wichtiger, weil aufstrebende Nutzer im Netz der KI-generierten Inhalte noch einen Unterschied machen können – außerhalb der moderierten Plattformen. Und für einen freien Zugang braucht man auch eine freie Adressvergabe und das geht nur, wenn – wie bei IPv6 – viele Adressen noch günstig verfügbar sind, ohne, dass man erst "digitales Land" für substanzielle Beträge abkaufen muss.

Die letzten wichtigen verbleibenden Bausteine für den Realtime-Support für Linux wurden in den Mainline-Zweig aufgenommen. Das bedeutet, dass Linux 6.12 voraussichtlich in einem echtzeitfähigen Modus betrieben werden kann, wenn der Kernel entsprechend kompiliert wird.

Echtzeitfähigkeit wird insbesondere in Embedded-Szenarien benötigt, wenn auf eine Eingabe innerhalb einer vorhersagbaren Zeit eine Antwort erwartet wird. Speziell in der Robotik, aber auch in der Multimediaproduktion gibt es solche Anforderungen. Dabei kommt es nicht darauf an, dass eine Aufgabe schnell abgearbeitet wird, sondern, dass sie in einer deterministischen Zeit begonnen wird.

Ein Beispiel für Echtzeit

An dieser Stelle mag sich die Frage stellen, was diese Echtzeitfähigkeit, von der hier geredet wird, überhaupt ist. Das lässt sich gut am Beispiel eines Line-following Robot klären. Was ein solcher Roboter tut, kann man sich z. B. in diesem YouTube-Video ansehen. Technisch besteht so ein Roboter aus zwei (oder mehr) Kameras als Sensoren, zwei Motoren für jeweils ein Rad als Aktoren und einem Controller zur Steuerung. Die Kameras sollen den Kontrast ermitteln, damit festgestellt werden kann, ob sie noch auf die schwarze Linie zeigen. Bemerkt eine der Kameras beim Fahren, dass sie den Sichtkontakt zur Linie aufgrund z. B. einer Kurve verliert, müssen die Motoren durch eine leichte Drehung nachsteuern, um auf der Linie zu bleiben.

Diese Kameras lösen üblicherweise entsprechend ihrer Abtastfrequenz auf dem Controller für die Steuerung einen Interrupt aus. Das führt zur Abarbeitung der Steuerungsroutine, die für beide Motoren die Geschwindigkeit berechnet, mit der sie sich drehen sollen.

Entscheidend ist, dass nicht beide Kameras den Sichtkontakt verlieren, damit der Roboter weiterhin weiß, in welche Richtung er nachsteuern muss. Üblicherweise wird das beim Testen funktionieren, aber es kann in bestimmten Randbedingungen bei normalen Betriebssystemen, wenn der Controller z. B. mit vielen anderen Aufgaben zufälligerweise beschäftigt ist, passieren, dass auf einmal nicht schnell genug die Routine aufgerufen wird. Der Roboter verliert dann den Sichtkontakt.

Der Entwickler eines solchen Roboters kann nun eine Echtzeitanforderung formulieren, dass z. B. auf ein Interrupt von den Kameras innerhalb von 1 Millisekunde reagiert werden muss. Er kann mit dieser Anforderung jetzt die maximale Geschwindigkeit des Roboters so wählen, dass der Roboter langsam genug fährt, um nicht die Linie – trotz der Latenz von im worst-case 1 Millisekunde – nicht zu verlieren.

Diese 1 Millisekunde muss aber auch vom Controller, seinem Betriebssystem und schließlich seinem Kernel garantiert werden. Der Kernel muss also in jeder Situation in der Lage sein, auf eine Anforderung innerhalb einer vorbestimmten Zeit zu reagieren. Unabhängig von der zwingenden Fähigkeit, präemptiv zu arbeiten, also jederzeit anderer Prozesse unterbrechen zu können, darf der Kernel auch nicht mit sich selber unvorhersehbar lange beschäftigt sein, wenn z. B. eine Synchronisation hängt.

20 Jahre Arbeit

Und genau hierum geht es beim grob gesagt beim PREEMPT_RT-Patch. Der Kernel muss so nachgebessert werden, dass keine Komponente sich unnötig lange aufhängt und somit die Abarbeitung von Aufgaben behindert, für die eine garantierte Ausführungszeit festgelegt wurde.

Die ursprüngliche Arbeit begann bereits im Jahr 2004 auf einem getrennten Zweig und hatte viele Verbesserungen in den Kernel gebracht, zuletzt an der printk()-Infrastruktur. Jetzt sollten die Arbeiten so weit sein, dass Realtime nicht mehr auf einem getrennten Zweig, sondern im Hauptzweig entwickelt werden kann.

Die Echtzeitfähigkeit gab es somit in speziell präparierten Kernels schon lange. Neu ist, dass der Code im Hauptzweig gepflegt wird und somit besser mit Änderungen anderer Maintainer abgestimmt werden kann. Denn eine Änderung an einer anderen Komponente reicht schon aus, um die Echtzeitfähigkeit zu unterminieren.

Linux echtzeitfähig zu machen, ist somit ein großer Aufwand gewesen, weil man solche Fähigkeiten oft nur in spezialisierten Betriebssystemen (sogenannten Real-time operating systems, RTOS) vorfindet. Insbesondere Thomas Gleixner und John Ogness haben hier große Anstrengungen unternommen. Jetzt, nach knapp 20 Jahren Arbeit, dürfte das Vorhaben einen wichtigen Meilenstein erreichen.

Wer sich für einen tieferen Einblick in die Linux-RT-Welt interessiert, kann einerseits den Artikel von Thomas Leemhuis auf Heise Online von letzter Woche lesen oder sich auf LWN durch das Artikelarchiv zu der Thematik arbeiten.

Interessanter Gegentrend: Während ich vor ziemlich genau einem Jahr über das zu der Zeit aktuellste Beispiel HashiCorp schrieb, wo eine Umstellung auf BSL-artige Lizenzen erfolgte, scheint es wohl auch einige Kandidaten zu geben, die wieder auf OSI-genehmigte Lizenzen umstellen. So verkündete Elastic am vergangenen Donnerstag, das sie wieder mit ihrer Suchmaschinensoftware Elasticsearch "Open Source" werden möchten, indem sie die AGPL als Lizenzoption aufnehmen.

Hintergrund

Hier einmal der Hintergrund bis jetzt, so wie es auf mich als externen Beobachter wirkte: Open Source hat es im Zeitalter der Cloud recht schwer, wenn man damit Geld verdienen möchte (um z. B. die Entwicklung zu finanzieren!). Das verbreitete Standardmodell zur Monetarisierung war bisher, eine Software Open Source anzubieten und den Support oder das Hosting kostenpflichtig anzubieten. Aus Kundensicht bestellt man dann direkt bei dem Hersteller, der seine Software auch am besten verstehen sollte.

Cloud Provider haben dem Modell das Wasser abgegraben, da sie einfach die Open Source Software nehmen und auf ihrer Plattform deployen konnten – ohne einen Cent dem Projekt zahlen zu müssen. Teilweise wurde die Software erweitert, ohne, die Änderungen wieder veröffentlichen zu müssen (deswegen sind auch die MIT- und BSD-Lizenzen so beliebt). Aus Kundensicht kauft man zwar nicht mehr bei dem Hersteller ein, hat aber

• einerseits alles zentralisiert auf einer Cloudplattform und
• andererseits gar keinen Bedarf für Herstellersupport, weil die Software sowieso über das SaaS-Modell supported wird und nicht mehr on-premise läuft.

Die Antwort vieler Projekte war es nun, die Lizenz so zu ändern, dass dieses Verhalten nicht mehr möglich ist, z. B. durch die Beschränkung von Konkurrenz-Hostingprodukten. Das verstößt allerdings gegen das Diskriminierungsverbot der OSI, nach dem die Verwendung von Produkten nicht durch die Lizenz beschränkt werden sollte (siehe auch das Good-Evil-Thema bei der JSON-Lizenz).

In der Konsequenz spalteten sich wie mit Open Search Elasticsearch-Forks ab, die weiterhin die offenen Lizenzen nutzen und durch Cloud Provider wie AWS direkt gepflegt wurden und werden. Wie Elasticsearch betont, sollen diese Projekte aber gleichzeitig auch einen eigenen Weg mit eigener Spezialisierung entwickelt haben. Die Community war natürlich aber auch verärgert, da die Software Elasticsearch nun nicht mehr als Free Open Source Software (FOSS) galt.

Wieder Open Source

Elasticsearch plant nun die Wogen zu glätten, indem die AGPL als weitere Lizenz zur ELv2 und SSPL zusätzlich aufgenommen wird. Die Nutzer können also frei entscheiden, welche Lizenz sie nutzen wollen, da insbesondere im Geschäftskontext die AGPL juristisch gesehen als heikel eingeschätzt wird, wenn man das Produkt aus verschiedenen Komponenten zusammengebaut und nicht den gesamten Quelltext veröffentlichen möchte. FOSS-Nutzer und Distributionen haben allerdings wieder die Möglichkeit, die Software wiederaufzunehmen. So entspricht z. B. die AGPL den Debian Free Software Guidelines.

Ende gut, alles gut? Wenn es nach der Ankündigung von Elastic geht, ist das Team zufrieden mit der Entscheidung, wieder Open Source zu sein. Ob der Fork OpenSearch aufrecht erhalten wird oder schlussendlich in das Urprodukt einfließt, ist allerdings noch nicht gewiss und muss sich in der Zukunft zeigen. Vielleicht sind die Communities auch schon zu sehr divergiert, sodass es nun unterschiedliche Lösungen für unterschiedliche Anwendungsfälle gibt.

Wer sagte noch gleich, dass klassische Release-Distributionen den Rolling Releases überlegen sind, weil sie so stabil seien? Dass es Ausnahmen von der Regel gibt, durfte ich heute erleben. Ich liebe diese Tage, wo auf einmal die normalsten Dinge nicht mehr gehen...

Es galt etwas in einem Softwareprojekt zu testen, das ich hierfür erstmal wieder in Gang bringen musste. Dabei setzt das Projekt auf Vagrant in Kombination mit VirtualBox. Ich habe dazu erstmal das Hostsystem aktualisiert und versucht, mit Vagrant die Maschine aufzusetzen – um dann feststellen zu dürfen, dass Vagrant einen Fehler wirft.

Was ging schief?

Konkret war VirtualBox in die Guru Meditation gefallen. Das tritt dann auf, wenn ein besonders schwerer Fehler auftritt, sodass das Programm nicht ordentlich weiterlaufen kann. Dabei war doch gar nicht viel am Entwicklungssystem verändert worden? Ich halte für solche Entwicklungsprojekte dedizierte Entwicklungsmaschinen vor, auf denen sich das Betriebssystem über die Jahre nicht verändert und die für die tägliche Arbeit auch entsprechend nicht eingesetzt werden. Was ich aber tue: die Zwischenupdates einspielen.

Stellt sich heraus, dass unter Ubuntu 22.04 LTS die Kernelversionen ab 5.15.0-112 den Fehler VERR_VMM_SET_JMP_ABORTED_RESUME wohl verursachen. Der Bug wird schon auf Launchpad, bei ubuntuusers.de und auch im VirtualBox-Forum diskutiert.

Wie kann man das fixen?

Man könnte einereits den Kernel downgraden bzw. einen alten Kernel nutzen, was aber nur kurzfristig Abhilfe schafft. Alternativ gibt es die Flucht nach vorne: entweder Ubuntu auf 24.04 LTS upgraden (habe ich nicht probiert, scheinbar ist der automatische Update-Pfad auch noch gar nicht freigeschaltet) oder VirtualBox auf Version 7.0 updaten. Ich habe mich für letzteren Schritt entschieden und dabei auf die offiziellen VirtualBox-Pakete von Oracle zurückgegriffen, da in den offiziellen Ubuntu-Repos für die Version nur Version 6.1 enthalten ist (was ja bei LTS-Versionen eigentlich auch sinnvoll ist). Das ist natürlich keine schöne Lösung, da man sich fremde Pakete in das System holt – aber sie funktioniert. Man muss allerdings auch bedenken, dass die aktuelle Vagrant-Version, die in den Ubuntu-Repos für 22.04 (jammy) enthalten ist, VirtualBox 7.0 noch gar nicht unterstützt. Folglich muss man dann auch auf die offiziellen Repositories von Hashicorp zurückgreifen – was allerdings angesichts der lizenzrechtlichen Änderungen sowieso bald nötig wird.

Was lernen wir daraus?

Software muss laufend auf Regressionsfehler getestet werden, die durch Updates an anderen Stellen passieren können. Ja, diese Fehler können immer passieren und sind teilweise schwer zu verhindern. Gleichzeitig muss man aber selber auch seine Setups regelmäßig testen, um schnell zu erkennen, dass ggfs. das Kernelupdate schuld war. Mittlerweile vermutet man das aufgrund der Stabilität der Systeme schon fast gar nicht mehr. Ansonsten geht viel Zeit aufgrund der Fehlersuche ins Land. Da ist es auch wenig zuträglich, dass die VirtualBox-Logs scheinbar keine Log Level beinhalten...

Ein Fix seitens Ubuntu steht für diesen Bug im Übrigen noch aus. Theoretisch sollte sich dann das Thema von selbst erledigen, weil die betreffende Änderung im Kernel einfach reverted wird. Ich wollte zwischenzeitlich aber die Workarounds einmal auflisten, sollte jemand ähnliche Probleme haben.

Dem Forscherteam von Qualys ist es gelungen, eine ältere Sicherheitslücke in OpenSSH, die schon eigentlich längst geschlossen war, erneut auszunutzen. Die neue Lücke wird als CVE-2024-6387 geführt und ist deswegen brisant, weil Sie bei Erfolg dem Angreifer Root-Rechte ohne vorherige Authentifizierung ermöglicht. Die nötigen Bedingungen für ein Ausnutzen der Lücke sind allerdings nicht ganz trivial.

Die gesamte Erläuterung der Sicherheitslücke ist im Bericht von Qualys umfangreich erläutert wollen. Wenn wir es schaffen, werden wir diesen schon Mittwoch im Risikozone-Podcast detaillierter erläutern.

So viel sei gesagt: die Lücke existierte schon mal als CVE-2006-5051, wurde dann gefixt und konnte jetzt (erstmals) ausgenutzt werden, da der eigentlich kritische Teil 2020 wieder versehentlich eingebaut wurde. Der Fehler selber baut darauf, dass syslog() zur Protokollierung asynchron aufgerufen wird, obwohl die Funktion nicht "async-signal-safe" ist. Kann ein Angreifer Timingeigenschaften ausnutzen, wird er in die Lage versetzt, Code einzuschleusen, der in einem privilegierten Teil von OpenSSH ausgeführt wird. Der Zeitaufwand ist allerdings hierfür nicht zu unterschätzen, da das Codefragment nur bei einem Verbindungstimeout aufgerufen wird.

Es ist gemäß des Qualys-Berichtes hervorzuheben:

• Die OpenSSH-Versionen vor 4.4p1 (2006) sind angreifbar, sofern sie nicht explizit gepatcht wurden.
• Die OpenSSH-Versionen zwischen 4.4p1 und 8.5p1 (2021) hatten nicht den besagten Code drin.
• Die OpenSSH-Versionen ab 8.5p1 hatten den Code wieder drin.
• Mit OpenSSH 9.8p1 wurde die Lücke gepatcht.

Mit anderen Worten: abhängig von eurem System ist die Schwachstelle vorhanden, weswegen ihr in eure Distribution schauen solltet, ob es Updates gibt.

OpenSSH ist nichtsdestotrotz im Hinblick auf seine Rolle und Exposition eines der sichersten Programme der Welt. Die Software ist ein sehr stringent abgesicherter Dienst, der u. a. auf Sandboxing-Mechansimen setzt, um den Umfang der Codesegmente, die als root ausgeführt werden, gering zu halten. Diese Lücke ist eine der seltenen Situationen, in der trotzdem ein Security-Bug vorhanden ist. Dabei ist eine Ausnutzung vergleichsweise aufwändig.

Kurz notiert: Debian 10 mit dem Codenamen "buster" erreicht heute das End of Life. Die Unterstützung wurde bis 2022 vom Debian-Team bereitgestellt und dann bis zum heutigen Tage durch das LTS-Team sichergestellt. Damit wurde Debian 10 knapp fünf Jahre durchgängig unterstützt.

Debian 10 wurde am 6. Juli 2019 und somit vor knapp fünf Jahren veröffentlicht. Ausgeliefert wurde das Betriebssystem mit dem Linux-Kernel 4.19. Der letzte Point-Release erfolgte am 10. September 2022, damit endete auch der klassische Security-Support.

Anschließend hat das LTS-Team die Unterstützung am 1. August 2022 mit einer Teilmenge von Architekturen (amd64, i386, amd64, armhf) übernommen, damit Nutzer wichtige Sicherheitsupdates noch erhalten und die Gelegenheit haben, auf den Folge-Release umzustellen. Diese Unterstützung läuft am heutigen Tage aus.

Es ist somit an der Zeit, auf Debian 11 mit dem Codenamen "bullseye" umzustellen. Die Migrationsanleitung ist in den Release Notes für Debian 11 zu finden. Hier wird auch erläutert, mit welchen Breaking Changes zu rechnen ist. Wie üblich, lässt sich der Release über die APT-Konfiguration anheben, gefolgt von einem Upgrade über APT. Die wichtigste Änderung dabei ist, dass das Security-Archiv ein neues Layout hat. Ich habe einige Systeme schon aktualisiert, dabei gab es bei mir keine Probleme. Das sollte auch bei anderen Systemen keine Schwierigkeiten bereiten, wenn sich an den offiziellen Debian-Paketquellen orientiert wird. Die Backports sollte man aber kontrollieren, wenn z. B. ein Backports-Kernel genutzt wurde, um WireGuard schon mit Debian 10 nutzen zu können (erst Debian 11 hat eine Kernelversion, in der WireGuard integriert ist).

Aktuell werden vom Debian-Team die Versionen 11 (bullseye) und 12 (bookworm) als Hauptversionen gepflegt. Das LTS-Team ist eine Gruppe von Freiwilligen, die sich zum Ziel gesetzt hat, eine fünfjährige Unterstützung für Debian-Versionen sicherzustellen. Wer eine zehnjährige Unterstützung benötigt, kann auf entgeltliche ELTS-Angebote wie z. B. von Freexian zurückgreifen.

Ich hatte es geahnt, aber dann ging es doch schneller als gedacht. Mit der Entscheidung des Europäischen Gerichtshofes Ende April wurde in einem Fall in Frankreich die Speicherung von IP-Adressen seitens des ISPs auf Vorrat nicht nur für den Bereich schwerer Straftaten, sondern auch für Urheberrechtsverstöße für zulässig erachtet. Damit ist eine Diskussion wieder auf dem Tisch, die seit 20 Jahren regelmäßig aufflammt, aber bisher durch Urteile gegen die erlassenen Gesetze eingefangen wurde.

Mit diesem Thema haben wir uns vergangene Woche mit Professor Dr. Stephan G. Humer in der 48. Episode des Risikozone-Podcasts beschäftigt, den ich euch wärmstens empfehlen kann.

Die klassische VDS in Deutschland wird momentan nicht praktiziert, da sie nach einem älteren Urteil des EuGH, das konkret das deutsche Gesetz betraf, als rechtswidrig eingestuft wurde. Nichtsdestotrotz ist die Diskussion wieder eröffnet und alle Möglichkeiten für Vorhaben zur Wiedereinführung werden wieder eingebracht. Das Thema wird uns also weiterhin noch eine ganze Weile verfolgen.

Klar, im Urteil des EuGH wird als Bedingung gestellt, dass Maßnahmen getroffen werden müssen, damit die Privatsphäre der einzelnen Nutzer gewahrt bleibt, aber das ändert nichts daran, dass die Daten grundsätzlich erstmal erhoben werden. Die "Neuerung" in diesem Urteil zu der Thematik ist, dass IP-Adressen und Identitäten getrennt gespeichert werden müssen. Mir ist allerdings noch nicht einleuchtend, was im Urteil mit der "Verknüpfung nur unter Verwendung eines leistungsfähigen technischen Verfahrens [...], das die Wirksamkeit der strikten Trennung dieser Datenkategorien nicht in Frage stellt" gemeint ist. Sollen die Datenbanken mit einem anschließend zu verwerfenden Schlüssel verschlüsselt werden, der bei der Verknüpfung erst geknackt werden muss? Am Ende kann ein technisches Verfahren doch gar nicht feststellen, ob ein Gesuch den formellen juristischen Anforderungen genügt oder nicht.

Technisch reden wir hier im Übrigen von zwei Teilaspekten: einerseits die Speicherung, welche Stationen (mit welchen IP-Adressen) miteinander kommunizieren und andererseits, wer hinter welcher IP-Adresse steckt. Diese ganze letzte Thematik haben wir allerdings nur, weil die ISPs einerseits ungern Privatkunden feste IP-Adressen vergeben und andererseits mitunter gar nicht so viele IP(v4)-Adressen wie Kunden haben und dann zu Tricks wie CG-NAT greifen müssen. Hämisch könnte man jetzt fragen, warum in dem Zusammenhang die Politik noch nicht alle zu IPv6 verpflichtet hat. Auf der anderen Seite wird deutlich, wie sehr sich das Internet verändert hat, nachdem es ein Massenmedium wurde.

Früher wurden feste IP-Adressen genutzt und die Zuordnung größtenteils öffentlich hinterlegt. Die Teilnehmer des Internets kannten sich mehr oder weniger sowieso alle untereinander. Als das Internet mehr und mehr ein Massenmedium wurde, ging es allerdings nicht mehr um den wissenschaftlichen oder beruflichen Austausch, sondern auch vorrangiger um das private Leben, wodurch auf einmal Grundrechte tangiert wurden und das Thema der Anonymität im Netz aufkam.

Gespeichert werden die Zuordnungen wohl auch weiterhin noch, aber sichtbar sind sie nur noch für Behörden und ähnliche Organisationen. Spätestens mit dem breiten Ausrollen der DSGVO wurde z. B. der whois-Dienst der DENIC für die Öffentlichkeit geschlossen. Wer einen Webseitenbetreiber ermitteln möchte, der kein Impressum auf der Seite stehen hat, schaut seitdem in die Röhre.

Vorratsdatenspeicherung ist und bleibt somit ein netzpolitisches Thema und lässt sich somit nicht auf der rein technischen Ebene erklären. Von da aus kann man sich oft an den Kopf fassen, was da alles von der Technik erwartet wird. Solche Themen sind auch ein Abbild der Gesellschaftspolitik, was daran deutlich wird, dass im Wesentlichen Deutschland eines der wenigen kritischen Länder diesbezüglich ist.

Die Never-ending-Story geht jetzt also in die nächste Runde. Weitere Probleme, Risiken und Lösungsansätze könnt ihr gerne euch in unserem Podcast anhören und in den Kommentaren mitdiskutieren.

Heute erscheint die 46. Episode des Risikozone-Podcasts und die zweite Episode, in der es um die xz-Lücke geht. Während es in der vorangegangenen Folge um die technischen Details ging, haben wir uns diesmal der Frage gewidmet, wie so ein Eingriff gegen ein Open-Source-Projekt überhaupt möglich werden konnte. Antwort: Es war umfangreiche psychische Manipulation im Spiel.

Deswegen haben wir den Social-Engineering-Experten Stephan G. Humer eingeladen. Er hat eines der ersten regelmäßigen Social-Engineering-Seminare in Deutschland etabliert und erläutert, was Social Engineering eigentlich ist, welche Methoden angewendet werden und wie man sich davor schützen kann.

Mit der heutigen Episode versuchen wir unserem ganzheitlichen Slogan "Der Podcast über Sicherheit und Zuverlässigkeit moderner Technologien" gerecht(er) zu werden und reden nicht nur über technische Details, sondern auch über sozialwissenschaftliche Aspekte und Kultur. Open-Source-Projekte bestehen nämlich nicht nur aus Code, sondern auch aus vielen zwischenmenschlichen Interaktionen, die eine - wie wir mit der Lücke sehen - auch im Bezug auf Sicherheit nicht zu vernachlässigende Rolle einnehmen.

Um dem knapp zweistündigen Interview in einem Punkt vorwegzugreifen: es gibt keine Patentlösung. Social Engineering ist unvermeidbar und wer glaubt, er wäre dem gefeit, ist umso verwundbarer gegenüber Angriffen. Ein entscheidender Punkt ist aber Gelassenheit und damit verbunden Verantwortungsbewusstsein. Wer ein Projekt beginnt und damit wächst, sollte sich als Maintainer in der heutigen Welt umso mehr Gedanken machen, wie man die Last verteilt, wieder aussteigt und Entscheidungen nicht auf eine Person konzentriert. Die Situation, als Maintainer wenig Zeit für ein Projekt zu haben, ist zwar im Einzelfall natürlich menschlich verständlich, aber ein Warnsignal.

Wir werden auf Zeiten keine zufriedenstellende Lösung finden und mit vereinfachten Lösungsansätzen arbeiten. Trotzdem ist es wichtig, ob solcher Angriffe zu wissen und wenigstens eine gesunde Skepsis an den Tag zu legen.

Wie seht ihr das? Wir freuen uns auf euer Feedback!

Seit 1,5 Jahren produziere ich den Podcast Risikozone, in dem es um Themen der IT-Sicherheit und Open-Source-Software geht. Die xz-Backdoor ist natürlich ein heißes Thema, weswegen es in der heute veröffentlichten Episode 45 genau darum geht.

Die knapp einstündige Podcastepisode ist für alle interessant, die nochmals einen technisch orientierten Überblick über die Geschehnisse suchen. Da die Thematik recht komplex ist und aus verschiedenen Blickwinkeln beobachtet werden kann, können weitere Podcastepisoden hierüber noch folgen. Ich möchte aber darauf eingehen, dass man diese Backdoor nicht nur auf den Code beschränken sollte. Es gibt es viele verschiedene Ebenen, die allesamt jeweils Beachtung finden sollten:

• die technische "Exploit"-Ebene
• die zwischenmenschliche Ebene
• die Ökosystem-Ebene

Technisch ist der Exploit ausgeklügelt: Die Backdoor beschränkt sich nicht nur auf die bloße Möglichkeit einer Remote-Code-Execution, sondern verwendet darüber hinaus noch ein eigenes Protokoll, mit dem die Befehle signiert und verschlüsselt innerhalb des unscheinbaren N-Wertes im Zertifikat eines SSH-Handshakes übermittelt werden. Durch die Signatur können nur Befehle ausgeführt werden, die mit einem (wahrscheinlich nur dem Angreifer bekannten) ED448-Schlüssel signiert wurden. Die Verschlüsselung erfolgt zwar mit einem statischen Schlüssel, der aus dem ED448-PubKey abgeleitet wird, erfüllt jedoch trotzdem seinen Zweck: Obfuskierung. Mit anderen Worten: wäre die Lücke nie aufgefallen, hätte man sie in der freien Wildbahn nahezu unmöglich durch Traffic-Analysen finden können.

Das ist allerdings nur die erste von drei Ebenen: die Art und Weise, wie die Lücke hereingeschummelt wurde, weist Komponenten des Social Engineering auf. Die Mühe, über mehrere Jahre eine Identität in verschiedenen Projekten mit teils anfangs legitimen Beiträgen aufzubauen, zeugt auch von einem Plan und Ausdauer.

Schlussendlich sollte man auch nicht vergessen, dass hier eine besondere Konstellation im Ökosystem ausgenutzt wurde. Am einfachsten (und auffälligsten) wäre es, eine solche Lücke in OpenSSH unterzubringen. Es wurde aber auf eine deutlich unbeachtetere und einfacher zu infiltrierende Variante ausgewichen. Die xz-Bibliothek wurde zudem nicht zum Einfallstor, weil OpenSSH darauf zurückgreift (das tut es nämlich nicht), sondern weil einige Distros systemd-notify reinpatchen, was wiederum auf die xz-Lib zurückgreift. Außerdem rüttelt dieser Fall an einem Grundpfeiler der IT-Sicherheits-Praktiken: Updates. Diese Hintertür fand geradezu durch die (häufigen) Updates der Rolling-Release-Distros Einzug - die stabilen Versionen waren noch verschont geblieben. Ist also (zu) häufiges Updaten nun auch nicht mehr richtig? Bringen bald Updates mehr Lücken als sie schließen?

Das alles macht es vor allem noch schwieriger, solche Angriffe zuverlässig zu erkennen. Zudem ist davon auszugehen, dass die Angreifer sich die Verteidigungsstrategie jetzt ganz genau anschauen. Die zukünftige Diskussion sollte sich also darauf konzentrieren, wie man diese Art von Angriffen detektiert und frühzeitig eindämmt.

Die weitverbreiteten Datenkompressionswerkzeuge XZ Utils (früher LZMA Utils) enthalten in Version 5.6 eine Backdoor. Ziel der Backdoor ist nach aktuellem Kenntnisstand eine Kompromittierung von SSH-Servern. Dies wurde gestern auf der oss-security-Mailingliste von Andres Freund nebst einer umfangreichen Analyse des Sachverhalts bekannt gegeben. Durch den Einsatz der Werkzeuge in Linux-Distributionen haben wir hier einen Fall einer Supply-Chain-Attacke. Red Hat hat dem Vorfall die CVE-Nummer CVE-2024-3094 vergeben.

Vorab eine Liste mit weiteren Links:

• Stellungsnahmen von verschiedenen Distributoren
  • Arch Linux
  • Debian
  • Red Hat
  • SUSE
• FAQ
• Hacker-News-Diskussion
• Zeitleiste

Wirkungsweise

Dabei wird die Backdoor nur unter bestimmten Bedingungen ausgeführt, wie das FAQ beschreibt. Im Wesentlichen muss argv[0] auf /usr/sbin/sshd gesetzt sein und eine Reihe an Umgebungsvariablen entweder gesetzt oder nicht gesetzt sein. Normalerweise hängt OpenSSH nicht von liblzma ab. Einige Distributoren patchen OpenSSH allerdings so, dass systemd-Notifcations funktioniert, welches wiederum auf liblzma setzt und die Backdoor möglich macht. Technisch werden einige Checks durchgeführt und anschließend mittels IFUNC Bibliotheksaufrufe umgeleitet. Dies betrifft nach aktuellem Stand auch Aufrufe während der Kryptoroutinen bei der SSH-Authentifizierung.

Betroffenheit

Der Wirkungsweise der Payload ist noch nicht abschließend geklärt. Besonders auch aus diesem Grund wird ein unverzügliches Update angeraten. Im Folgenden einige unverbindliche Faktoren, die eine Verwundbarkeit wahrscheinlich machen. Auf diese Weise kann man priorisieren, welche Systeme zuerst aktualisiert werden sollten.

Versionierte Distros wie z. B. Debian oder RHEL sind nach aktuellem Kenntnisstand mit ihren stabilen Versionen nicht direkt betroffen, da die Versionen 5.6 noch keinen Einzug in das System gefunden haben. Die Testing-Versionen dieser Distros wie z. B. Debian Sid wurden allerdings aktualisiert und sind betroffen.

Rolling-Release-Distros sind naturgemäß auch betroffen, wenn sie schon Version 5.6 in ihre Pakete aufgenommen haben. Dies betrifft zum Beispiel Arch Linux oder Gentoo. Da allerdings einige Distributionen wie Arch Linux OpenSSH nicht gegen liblzma linken, wird die Bibliothek nicht direkt in die Ausführung der Komponenten eingebunden.

Nach aktuellem Stand wird eine Verwundbarkeit besonders kritisch, wenn auf dem betroffenen Host ein öffentlich erreichbarer SSH-Server läuft, da die oben beschriebenen Faktoren ein Laden der Payload auslösen können.

Wie kam es?

Aufgefallen ist die Backdoor nur durch Zufall durch das Debugging von Performanceproblemen, die durch die Backdoor verursacht wurden. Die Backdoor wurde obfuskiert im Rahmen von Buildskripten untergebracht, sodass aufgrund der Komplexität die Lücken noch nicht direkt aufgefallen sind.

Das Repository hinter xz kann als kompromittiert gesehen werden und ist auch auf GitHub schon gesperrt worden. Auffällig ist, dass die Backdoor in den Tarballs der Releases enthalten war, nicht jedoch im Repository-Dump selber. Auch personell gab es einige Auffälligkeiten, da es vor kurzem einen Maintainerwechsel beim Projekt gab und die Lücken vom neuen Maintainer, der seit 2 Jahren am Projekt mitarbeitet, zumindest begünstigt wurden. Die Art und Weise lässt auch auf ein koordiniertes, von langer Hand geplantes Vorgehen schließen.

Einfluss und Folgen

Das große Ganze ist ein Paradebeispiel von xkcd 2347 "Dependency". Wir sehen hier Live ein Beispiel einer Supply-Chain-Attacke. Ein kleines, scheinbar unbedeutendendes Projekt wird übernommen, nur um strategisch Commits zu platzieren, die automatisch "flussabwärts" ihren Weg in größere Distributionen finden, die allesamt auf das Projekt setzen. Alles passiert trotz Open Source. Besonders pikant: der Maintainer hat aktiv versucht, die Backdoor-begünstigenden Umgebungsfaktoren, konkret das Umbiegen von Bibliotheksaufrufen mittels ifunc, in Fuzzing-Projekten wie oss-fuzz, die aktiv nach sowas suchen, zu deaktivieren.

Software wird immer bedeutender und benötigt Vertrauen. Dabei ist jetzt schon klar, dass niemand selber solch komplexe Systeme von alleine bauen kann. Aber auch die Kontrolle der Quellen ist eine große Herausforderung. Neue Gesetzgebung wie der geplante Cyber Resilience Act in der EU versuchen in der Industrie Anreize zu schaffen, die Softwarequalität zu erhöhen.

Diese Attacke konnte einigermaßen abgewendet werden, sollte die umfassende Analyse der Payload keine belastenden Neuigkeiten hervorbringen. Eines ist aber auch klar: Die Angreifer studieren das Verhalten der Verteidiger und werden in Zukunft ihre Vorgehensweise dahingehend optimieren, nicht so einfach mehr gefunden zu werden. Es ist also möglich, Backdoors in so ein Ökosystem hineinzuschummeln. Umso besser müssen aber die Identifikations- und Abwehrmöglichkeiten werden, damit solche Angriffe wirksam verhindert werden können.

Kurz notiert: heute wurde die Desktopumgebung Plasma 6 aus dem KDE-Projekt freigegeben. Mit dem Umstieg auf Qt 6 und den einhergehenden Arbeiten ist es nach knapp 10 Jahren der erste große Major-Release (KDE Plasma 5 wurde 2014 veröffentlicht). Eine weitere wegweisende Änderung ist, dass der Fokus nun klar auf dem Display-Server Wayland liegt, der auch nun zur Standardeinstellung wurde. X11 wird jedoch weiterhin unterstützt.

Eine Auswahl der weiteren Änderungen:

• Es gibt einen neuen Overview-Effekt.
• Durch Wayland wird nun auch HDR unterstützt.
• Es gibt neue Filter zur Unterstützung bei Farbenblindheit.
• Das Einstellungsprogramm wurde überarbeitet.
• Der bekannte KDE Cube ist zurück.
• Neue Standardeinstellungen:
  • Dateien/Verzeichnisse werden nun mit einem Klick ausgewählt und mit einem Doppelklick geöffnet.
  • Das Panel ist nun standardmäßig schwebend.
  • Thumbnail-Grid ist nun der Standard-Task-Switcher.
  • Scrollen auf dem Desktop führt nun nicht mehr zum Wechsel der virtuellen Desktops.

Auch die KDE-Anwendungen erfahren umfangreiche Updates. All diese Informationen können im Release Announcement nachvollzogen werden.

KDE Plasma 6 sollte nun sukzessive auch in die Distributionen Einzug halten. Arch Linux ist als Beispiel für einen Rolling Release da schon schnell dabei. Ob und inwiefern komplexe Setups des traditionell sehr einstellbaren Desktop-Systems umgezogen werden können, wird sich dann zeigen. Ein großer Vorteil des KDE-Ansatzes zeigt sich allerdings schon im Release-Announcement: viele der Funktionen können genutzt werden, müssen es aber nicht. Dem Endanwender wird die Wahl überlassen, welche Optionen er nutzen möchte.

Es gibt wieder neue Sicherheitslücken in glibc. Dabei betrifft eine die syslog()-Funktion, die andere qsort(). Letztere Lücke existiert dabei seit glibc 1.04 und somit seit 1992. Entdeckt und beschrieben wurden die Lücken von der Threat Research Unit bei Qualys.

Die syslog-Lücke ist ab Version 2.37 seit 2022 enthalten und betrifft somit die eher die neuen Versionen von Linux-Distributionen wie Debian ab Version 12 oder Fedora ab Version 37. Hierbei handelt es sich um einen "heap-based buffer overflow" in Verbindung mit argv[0]. Somit ist zwar der Anwendungsvektor schwieriger auszunutzen, weil in wenigen Szenarien dieses Argument (der Programmname) dem Nutzer direkt überlassen wird, die Auswirkungen sind jedoch umso schwerwiegender. Mit der Lücke wird eine lokale Privilegienausweitung möglich. Die Lücke wird unter den CVE-Nummern 2023-6246, 2023-6779 und 2023-6780 geführt.

Bei der qsort-Lücke ist eine Memory Corruption möglich, da Speichergrenzen an einer Stelle nicht überprüft werden. Hierfür sind allerdings bestimmte Voraussetzungen nötig: die Anwendung muss qsort() mit einer nicht-transitiven Vergleichsfunktion nutzen (die allerdings auch nicht POSIX- und ISO-C-konform wären) und über eine große Menge an zu sortierenden Elementen verfügen, die vom Angreifer bestimmt werden. Dabei kann ein malloc-Aufruf gestört werden, der dann zu weiteren Angriffen führen kann. Das Besondere an dieser Lücke ist ihr Alter, da sie bereits im September 1992 ihren Weg in eine der ersten glibc-Versionen fand.

Bei der GNU C-Bibliothek (glibc) handelt es sich um eine freie Implementierung der C-Standard-Bibliothek. Sie wird seit 1987 entwickelt und ist aktuell in Version 2.38 verfügbar. Morgen, am 1. Februar, erscheint Version 2.39.

Es ist der 31.12.2023 und somit wird es wieder Zeit für den traditionellen Jahresrückblick. Dieses Jahr dominierten zwei Buchstaben: KI. Die Veröffentlichung von ChatGPT erfolgte zwar kurz vor 2023, in diesem Jahr wurden allerdings die Auswirkungen sichtbar. Ich muss sagen, dass es lange kein Werkzeug gab, an dem ich so viel Experimentierfreude erleben konnte.

Dabei ist die Mensch-Maschine-Schnittstelle besonders spannend. Die natürlichsprachliche Interaktion verbessert nicht nur die Zugänglichkeit, sondern erhöht auch die Interoperabilität: Das Werkzeug kann nicht nur die Aufgabe verstehen, sondern die Ergebnisse in der gewünschten Form darstellen. Schreibe ich eine Software, erfüllt sie nur einen Zweck. ChatGPT kann besonders einfach an neue Aufgabenbereiche angepasst werden. Man muss nicht einmal im klassischen Sinne "programmieren". Somit wird die Arbeit mit dem Computer auf eine ganz neue Stufe gehoben.

Auf die technische Ebene möchte ich heute gar nicht direkt eingehen, das haben wir das Jahr schon im Detail in diesem Blog ergründet. Diskussionen über Technik und Innovationen stellen nur eine Augenblickaufnahme dar. Im Rückblick auf eine größere Zeitepisode wie ein mindestens Jahr werden allerdings gesellschaftliche Entwicklungen deutlich. Und hier gab es einiges zu beobachten.

KI für die Massen

ChatGPT hat eine große Nutzerbasis erreicht, die zumindest ein Mal das Werkzeug ausprobiert hat. Im deutschsprachigen Raum, der sonst sich so "datenschutzorientiert" und innovationskritisch gibt, ist das schon bemerkenswert. Diskussionen über Datenschutz waren zweitrangig, die Menschen waren von der Innovation durch das Werkzeug fasziniert. Natürlich kam über das Jahr die Erkenntnis, dass in der aktuellen Form die Technologie je nach Branche noch nicht weit genug ausgereift ist, trotzdem wollte jeder einmal schauen, was es damit auf sich hat und ob es den Alltag erleichtern kann.

Und doch hat OpenAIs Werkzeug in meinen Augen ein wenig den Blick verengt: Durch das schnelle Wachstum wurde ChatGPT zum Sinnbild von "KI" und hat Ängste geschürt. Denn einerseits will jeder, dass KI ihm das Leben einfacher macht, jedoch nicht, dass andere mit KI ihm seine Lebenssituation verschlechtern bzw. ihn zu einem Umdenken zwingen. Ein Zeitungsredakteur möchte gerne KI für die Verbesserung seiner Texte einsetzen, fürchtet jedoch um seine Jobzukunft, wenn andere ihn durch automatische Generierung ganzer Zeitungsbeiträge drohen, überflüssig zu machen.

Dieser Umstand hat die Diskussion rund um den europäischen AI Act noch einmal deutlich angeheizt. An Large Language Models wurden auf einmal hohe Anforderungen gestellt, um subjektiven Ängsten entgegenzutreten. Dann war man sich aufgrund der Innovationsgeschwindigkeit auf einmal nicht sicher, ob es jetzt schon Zeit für eine starre Regulierung ist. Und schlussendlich zeichnet sich eine politische Entwicklung ab, jetzt lieber irgendeinen Kompromiss als später eine gut ausgearbeitete Fassung präsentieren zu können. Wie der AI Act kommt, werden wir dann im nächsten Jahr sehen.

Das alles war aber nicht das, was dieses Jahr in meinen Augen besonders gemacht hat. Es ist etwas anderes: die neue Rolle von Open Source.

Neue Hürden für Technologie?

Anfang des Jahres sah es so aus, als setzt eine besondere Kommerzialisierung in der Technikwelt ein: die Kommerzialisierung von Basistechnologie. Über die verschiedenen Jahre haben wir gesehen, dass es für verschiedene Produkte in der IT proprietäre und freie Lösungen gibt. Zwar sind erstere gerne technologisch mitunter überlegen, da die Profitorientierung Anreize setzt, für bestimmte Anwendungszwecke besonders passende Lösungen zu entwickeln. Kostet eine Software Geld, kann der Hersteller Programmierer anstellen, die auch die Features entwickeln, die man ungern freiwillig programmiert. Auf diese Weise entstehen runde Produkte für einen Anwendungszweck.

Freie bzw. zumindest quelloffene Software ermöglicht zumindest aber der Öffentlichkeit, einen Blick in die Funktionsweise zu werfen, um zu sehen, wie etwas funktioniert. Das ist die Grundlage, um Technologie zu verbessern.

In der Welt des maschinellen Lernens entstand allerdings durch die benötigte Compute Power eine hohe Eintrittshürde. Es sah so aus, als wären die Large Language Models nur noch großen Konzernen bzw. gut finanzierten Start-ups vorbehalten, die sich die Trainingspower leisten können. Während die Vorgängersysteme wie GPT-2 noch öffentlich zugänglich waren, wurden gerade Systeme wie GPT-3 und GPT-4, bei denen das Produkt endlich richtig nutzbar wurde, zurückgehalten.

Im Laufe des Frühlings habe ich allerdings vermutet, dass freie Modelle die proprietären outperformen können, weil die öffentliche Zugänglichkeit die Chance eröffnet, dass Experten weltweit mit ihren eigenen Erfahrungen, Eindrücken und ihrem Domänenwissen eine Technologie entwickeln können, die verschlossenen Produkten überlegen ist.

Überraschend war, dass es gerade das AI-Team von Facebook war, das den Stein mit LLaMA ins Rollen gebracht hat. Es folgten zahlreiche weitere Abkömmlinge, Weiterentwicklungen oder gänzliche Alternativansätze, die eines gemein hatten: ihr Kern mit den Gewichten war zugänglich.

Wie es aussieht, könnte die Dominanz proprietärer Systeme gebrochen werden, sodass auch die Möglichkeit gewahrt bleibt, einen wissenschaftlichen Diskurs zu führen. Technische Berichte proprietärer Modelle sind zwar nett, aber die Forschungsarbeiten, in denen reproduzierbare Fortschritte aufgezeigt werden, bringen uns tatsächlich eher voran.

Um die rasante Entwicklung im Frühling, als scheinbar jedes KI-Team großer Konzerne und Forschungseinrichtungen alle in der Schublade angesammelten LLM-Projekte zu veröffentlichen versuchte, im Auge zu behalten, habe ich die LLM-Timeline entwickelt. Sie wurde vor einigen Tagen wieder aktualisiert und zeigt besonders, wie sehr LLaMA als eines der ersten praktisch verwertbaren Modelle mit offenen Gewichten die Entwicklung beeinflusst hat.

Ein weiteres Projekt, das ich in der Zusammenarbeit mit der Fachhochschule Kiel realisiert habe, war der Podcast KI & Kultur, der generative Modelle aus der Perspektive Kulturschaffender beleuchtet hat.

Was bleibt

Das Jahr hat den 70 Jahre alten Begriff der KI wieder mal in die Massen gebracht. Dabei wird ChatGPT dem Begriff eigentlich gar nicht gerecht, weil es streng genommen relativ dumm ist. Insbesondere beschränkt es die Zustandsfähigkeit nur auf eine Prompt und lernt nicht, während es denkt. Training und Inferenz sind entkoppelt.

Und trotzdem ist es diese natürlichsprachliche Schnittstelle, die es so faszinierend macht. Allerdings ist auch diese Erkenntnis nicht neu und wurde schon vor 55 Jahren mit ELIZA diskutiert.

Erfreulich ist es, dass "Open Source" nicht mehr nur bei Software, sondern in neuen Technologien Anwendung findet. Der Gedanke, dass Technologie zugänglich sein muss, kann so erhalten werden. Und dass es hilft, wenn Wissenschaftler auf der ganzen Welt mit ihrem Wissen beitragen können, sehen wir weiterhin auch in dieser Thematik.

LLMs ermöglichen es, dass wir uns endlich wieder der Mensch-Maschine-Schnittstelle widmen können, die Technologie nutzbar macht. Menschen wollen, dass Technik das Leben einfacher macht. Die bisher begrenzte Rechenleistung hat uns zu Hilfsmitteln wie Displays, Touchscreens oder Tastaturen gezwungen. In den nächsten Jahren können wir schauen, wie wir das überwinden können, um endlich nutzbare Computer zu erhalten, die wirklich was bringen.

Und so ist es schon fast ironisch, dass die naheliegendste Technologie, die in den 2010er-Jahre euphorisch gefeiert wurde, von den LLMs noch wenig profitiert hat: Sprachassistenten. Sie sind überwiegend noch genau so begrenzt und unflexibel wie früher. Hier gibt es einiges zu tun.

Frohes Neues

Abschließend möchte ich meinen Lesern des Blogs und Zuhörern des Podcasts Risikozone sowie KI & Kultur danken, dass ihr den Blog lest, den Podcast hört und regelmäßig Feedback gebt. Ich wünsche euch einen guten Rutsch in das neue Jahr 2024.

Im nächsten Jahr werden wir wieder gemeinsam neue Technologien ergründen und die aktuellen Nachrichten diskutieren. Es wird auch mehr um Grundlagen und Visualisierungen gehen, hierauf freue ich mich schon besonders!

Viel Glück, Gesundheit und Erfolg!

Das Interessante an den Open-Source-Modellen ist ja, dass sie das umsetzen, was bei den proprietären Modellen gemunkelt wird, aber nicht nachgewiesen werden kann. Mein aktuelles Highlight: Mixture of Experts (MoE).

Im Sommer kamen Behauptungen auf, dass OpenAIs GPT-4 eigentlich aus acht kleineren Modellen besteht, die zusammengeschaltet werden. Dieses Verfahren nennt man auch Ensemble Learning.

Das klassische Beispiel dafür ist Random Forest, wo mehrere Decision Trees parallel zu so einem Ensemble zusammengeschaltet werden. Soll das Ensemble dann eine Klassifikation vornehmen, nimmt jeder Decision Tree mit seinen eigenen Gewichten die Klassifikation vor. Anschließend entscheidet die Mehrheit der Decision Trees im Ensemble, wie das Gesamtmodell nun klassifizieren soll. Analog würde auch eine Regression umgesetzt werden können, als Aggregierungsfunktion kommt dann statt Mehrheitswahl eben sowas wie Mittelwert o. ä. zum Einsatz. Das besondere ist, dass mit Random Forest üblicherweise bessere Vorhersagen erzielt werden können, als mit einem einfachen Decision Tree.

MoE funktioniert in den groben Zügen ähnlich. Es gibt "Experten" (ähnlich wie die Decision Trees bei Random Forest), die dann gewichtet aggregiert werden (Gating). Die Technik ist eigentlich recht alt und viele waren überrascht, dass OpenAI genau so etwas einsetzen soll.

Umso besser, dass Mistral als das europäische LLM-Startup sich der Sache angenommen hat. Anfang des Wochenendes schwirrte schon ein Torrent durchs Netz, heute gibt es dann auch eine offizielle Pressemitteilung zu Mixtral 8x7B. Hierbei handelt es sich um ein "Sparse Mixture of Experts"-Modell (SMoE). Die Gewichte sind wieder offen und unter der Apache 2.0 lizenziert.

Kurz zu den Eckdaten: 32k Token Kontextlänge können verarbeitet werden. Dabei spricht das Modell Englisch, Französisch, Italienisch, Deutsch und Spanisch und wurde auch auf Codegenerierung optimiert. Fine-tuning ist ebenfalls möglich - so wurde bereits eine instruction-following-Variante trainiert.

Im Vergleich zu Llama 2 70B soll es in einer Vielzahl von Benchmarks bessere Ergebnisse abliefern und dabei schneller arbeiten. Die einzelnen Ergebnisse können der Pressemitteilung entnommen werden.

Einen klassischen Downloadlink konnte ich auf die schnelle nicht finden, das Twitter-Profil verweist nur auf die Torrents. Parallel kündigt das Start-up an, einen eigenen Dienst für API-Endpoints anzubieten, sodass ein Deployment auf eigener Infrastruktur nicht mehr zwangsläufig notwendig ist.

Aktuell sollte beim Updaten des Linux-Kernels Vorsicht walten gelassen werden. Bestimmte Kernel-Releases weisen ein Problem mit ext4 auf, das theoretisch im schlimmsten Fall zu einer Datenbeschädigung führen kann.

Es gibt eine Konstellation, in der in einem Release nur der erste ohne den zweiten Commit enthalten ist und somit der Code nicht wie gewünscht arbeitet. Konkret geht es um

• 91562895f803: "ext4: properly sync file size update after O_SYNC direct IO" (ab v6.7-rc1)
• 936e114a245b6: "iomap: update ki_pos a little later in iomap_dio_complete" (ab v6.5-rc1)

Jan Karas E-Mail auf der LKML zufolge geht es darum, dass der erste Commit nur dann im Code vorhanden sein darf, wenn der zweite Commit bereits enthalten ist. Eigentlich ist das logisch, weil das ja mit der Reihenfolge dann auch so passt.

Jetzt kommen allerdings noch die Backports und Distributionen ins Spiel. Für den Kontext: da nicht jeder immer auf die neuste Linux-Version aktualisieren kann, gibt es ein Team, was alte Versionen nachpflegt und kleine, unkritische Fixes neuerer Versionen auf die älteren Versionen "rückportiert", also backported. Allerdings kann es nun passieren, dass etwas ganz neues rückportiert wird, ohne, dass eine ältere Voraussetzung rückportiert wurde. Die Fehler, die dann auftreten, nennt man klassicherweise eine Regression. Die einzelnen Codeänderungen sind da nicht an sich das Problem, sondern eher die Konstellation, in der sie zusammengesetzt wurden.

Linux 6.1.64 und 6.1.65 sind betroffen, 6.1.66 enthält den Fix. Debian 12, das auf die Kernels setzt, ist dabei besonders in Aufruhe, da eine problematische Kernel-Version verteilt wird. Aus diesem Grund wurde auch die Veröffentlichung von Debian 12.3 verzögert.

Weitere Informationen

• Ext4 data corruption in stable Kernels
• Debian-Bugreport 1057843

Kurz notiert: Nextcloud (Dateispeicher) und Roundcube (Webmail) gehen eine Partnerschaft ein. Wie heute das Nextcloud-Team in einer Blogmitteilung bekannt gab, wird Roundcube in die "Nextcloud family" aufgenommen. Dabei lässt sich die Kooperation in erster Linie strategisch verstehen, wird aber bereits kurzfristige Auswirkungen haben, da das Entwicklerteam des bekannten Webmail-Clients vergrößert werden kann.

Die wichtigste Information bei der Nachricht ist, dass Roundcube nach aktuellem Stand weiterhin als eigenes Produkt erhalten bleibt. Es handelt sich somit nicht um eine "Verschmelzung" bzw. "Übernahme" des Produkts.

Die Nachricht sendet allerdings ein positives Signal für produktiv eingesetzte Open-Source-Systeme aus: Nextcloud als ein in Unternehmensumgebungen weit verbreiter Cloud-Dienst (Dateispeicher, Kalender, etc.) ermöglicht anderen Büroprogrammen, sich weiterzuentwickeln und auf dem technisch aktuellen Stand zu bleiben. Dies meine ich dabei besonders im Sicherheitskontext. Zero-Days können immer auftreten, aber mit viel Entwicklungsressourcen kann die Wahrscheinlichkeit proaktiv gesenkt werden.

Nextcloud möchte somit auch einen attraktiven Gegenpol für klassische proprietäre Anwendungen aufbauen. Wir können also gespannt sein, was sich aus der Partnerschaft entwickelt.

Die gestrige Veröffentlichung von Linux 6.6 bedeutet, dass das Merge-Window wieder geöffnet ist. Ein erster Kandidat wurde bereits gemerged mit einem Vorhaben, das in den vergangenen Wochen zu vielen Diskussionen geführt hat: bcachefs.

Um bcachefs zu erklären, muss ich kurz ein wenig weiter ausholen. bcachefs geht - wie der Name schon vermuten lässt - auf bcache zurück. Hierbei handelt es sich um ein Kernelmodul, das Einzug in Linux 3.10 in 2013 fand und einen Caching-Layer für Block-Devices einführte.

Daten können somit hybrid zwischen ganz schnellem Speicher (RAM), schnellem Speicher (SSDs) und langsamem Speicher (HDD) aufgeteilt werden. Werden bestimmte Blöcke häufiger abgerufen, werden sie in den schnelleren Speicher verschoben und anders herum ebenso. Dabei handelte es sich aber immer um eine Zwischenschicht, auf der ein echtes Dateisystem aufbauen musste. Während der Entwicklung fiel dem Hauptentwickler Kent Overstreet jedoch schnell auf, dass zu einem "full-fledged" Filesystem nicht mehr viel fehlte.

Ein erster Prototyp entstand bereits im Jahre 2015 und hat somit die Ära der Dateisysteme der neusten Generation eingeläutet. Auch btrfs gehört zu diesen moderneren Dateisystemen und setzt auch auf das Copy-on-Write-Prinzip. Da die Blöcke einer Datei nicht bei einer Kopie dupliziert werden, spart dies Speicherplatz und ermöglicht verzögerungsfreie Snapshots.

bcachefs mit seinen über 90.000 Zeilen Code konnte zwar - wie für ein neues Dateisystem üblich und nötig - ausgiebig getestet werden, war allerdings bisher nicht im Mainline Linux vorhanden. Mitte des Jahres ging es dann an die Einarbeitung des Codes.

Eigentlich sollte bcachefs schon in Linux 6.5 Einzug halten. Aber aufgrund andauernder Spannungen wurde auch bei Linux 6.6 aus dem Vorhaben nichts. Eines der Probleme sind die teils umfangreichen Änderungen in fremden Modulen, die den Unmut der Maintainer auf sich gezogen haben. Wer sich dafür interessiert, kann sich den großen E-Mail-Thread ansehen. Linus Torvalds stand grundsätzlich einer Übernahme positiv gegenüber, wollte aber noch einen Test in linux-next abwarten. Dies ist zwischenzeitlich geschehen.

Nun also der Merge in den Kernel. Sollten sich die Änderungen bis zum Release halten, steht somit dem Einsatz des neuen Dateisystems ab der Veröffentlichung von Linux 6.7 nicht mehr viel im Wege. Die Aufnahme in Mainline vereinfacht aber auch die Entwicklung, da diese nun nicht mehr Out-of-Tree stattfindet, was aufgrund der hohen Änderungsgeschwindigkeit im Linux-Source-Tree schnell zu aufwändigen Anpassungsarbeiten führen kann.

Weitere Informationen zu bcachefs sind auf der eigenen Homepage abrufbar. Hier ist auch eine Schnellstartanleitung für den eigenen Einsatz zu finden.

Weitere Quellen

• Larabel: Bcachefs Merged Into The Linux 6.7 Kernel (31.10.2023)
• Larabel: Bcachefs Looks Like It Won't Make It For Linux 6.6 (08.09.2023)
• Larabel: Linus Torvalds Comments On Bcachefs Prospects For Linux 6.6 (06.09.2023)
• Thommes: Dateisystem Bcachefs für Linux 6.7 vorgesehen (31.10.2023)

Wer Exim4 als Mailserver einsetzt, wie es zum Beispiel in Debian-basierten Linux-Distributionen der Standard ist, sollte sich zeitnah um Updates bemühen oder - wenn der Dienst nicht zwangsläufig benötigt ist (bei manchen läuft Exim unbewusst) - spätestens jetzt gänzlich abschalten. Es gibt zumindest eine schwere Remote-Code-Execution-Sicherheitslücke.

Bleeping Computer berichtete über die Lücke(n), denn es geht um bis zu 6 Schwachstellen unterschiedlicher Stärke. Die genauen Details sind zum aktuellen Zeitpunkt noch nicht verfügbar, um Exploits nicht zu befördern. Es reicht allerdings unauthentifizierter Zugriff auf Port 25.

Der Fund geht auf die Zero Day Initiative von Trend Micro zurück. Sie hatte bereits im Juni letzten Jahres, also 2022, auf die Lücken aufmerksam gemacht. Besonders pikant: bis vor kurzem waren noch keine Patches verfügbar, zumal die schwerwiegende Lücke ZDI-23-1469 bereits Mitte der Woche veröffentlicht wurde.

Laut einer E-Mail der Entwickler ist ein bedeutenden Teil der Lücken bereits geschlossen und die Updates an die Distributoren verteilt. Dass die Lücke nicht schneller gefixt wurde, lag an Schwierigkeiten bei der Kommunikation. Bei Ubuntu wird die Lücke als CVE-2023-42115 geführt, hier sind noch keine Updates verfügbar.

Exim4-Admins sollten dies im Auge behalten und sofort reagieren. Mit ersten Exploits ist demnächst zu rechnen, wenn mehr über die Lücke bekannt wird. Der Mailserver ist weit verbreitet, es gibt laut Bleeping Computer mehrere Millionen Instanzen im Internet.

Das Wettrennen um die Technologieführerschaft der Large Language Models lief größtenteils bisher auf dem amerikanischen Kontinent ab. OpenAI hat das Produkt populär gemacht und Meta AI veröffentlicht den Konkurrenten mit den freien Gewichten. Mit Falcon 40B und 180B gab es allerdings schon Konkurrenz aus Abu Dhabi, zumal mit der gewählten Apache-2.0-Lizenz ein deutlich offenerer Ansatz gewählt wurde.

Als kurz vor dem Sommer das Start-up Mistral aus Paris 105 Millionen Euro eingesammelt hat, waren die Medienberichte zumindest leicht kritisch, da nicht nur das Start-up mit einer gigantischen Finanzierungssumme aus der Taufe gehoben wurde, sondern das Produkt auch noch gar nicht fertig war. Aus der LLM-Sicht ist dies allerdings verständlich, da solche großen Summen schlicht die Voraussetzung sind, um an den Start zu gehen. Schließlich benötigt Training leistungsfähige GPUs und die sind teuer.

Mit dem veröffentlichten Modell Mistral 7B zeigt das Start-up, was es kann. Dabei handelt es sich um ein LLM, das über 7 Mrd. Parameter verfügt und Llama 2 13B in allen und LLaMa 34B in vielen üblichen Benchmarks überbietet: Commonsense Reasoning, World Knowledge, Reading Comprehension, Math, Code, Popular aggregated results. In Codingaufgaben kann die Leistung von CodeLlama 7B erreicht werden.

Das Beste am LLM ist, dass es unter der Apache-2.0-Lizenz steht. Als klassische Open-Source-Lizenz gibt es nicht nur den Forschern und Entwicklern viele Freiheiten, sondern auch eine gewisse Lizenzsicherheit, dass das Modell in freier Software verwendet werden kann.

Ich hatte bereits vor Wochen geschrieben, dass freie Modelle eine gute Möglichkeit sind, um sich als neuer Player auf dem Markt zu profilieren. Diesen Plan verfolgt nicht nur Falcon, sondern nun auch offenbar Mistral. Es ist trotzdem davon auszugehen, dass die 105 Millionen Euro keine "Forschungsspende" waren und kommerzielle Produkte zeitnah folgen werden.

Für die Forscher und Entwickler von LLMs hat die aktuelle Veröffentlichung nichtsdestotrotz Vorteile. Meta AI hat mit der Lizenzgebung von Llama 2 auf die Open-Source-Bewegung in der LLM-Welt reagiert und sein aktuelles Modell unter eine permissive, aber trotzdem proprietäre Lizenz gestellt. Mistral geht allerdings noch einen Schritt weiter und setzt eine "klassische" Open-Source-Lizenz ein. Das hat nicht nur Signalwirkung, sondern ermöglicht, dass Unternehmen ihre LLM-Lösungen zunehmend privat hosten können, da die Parameteranzahl mit 7 Mrd. so dimensioniert ist, dass auch kleinere Datacenter-GPUs für die Ausführung bzw. Inferenz ausreichen. Es bleibt also weiterhin spannend im Umfeld der LLMs.

Die Mistral-7B-Modelle sind in Version 0.1 auf HuggingFace als normales Modell und als auf Chats spezialisiertes Modell (Instruct) verfügbar.

30 Jahre Debian - 30 Jahre felsenfeste Entwicklung und noch kein Ende in Sicht.

An diesem Tag vor 30 Jahren, am 16.08.1993, erschien in der Newsgroup comp.os.linux.development eine Ankündigung, die den Anfang eines der größten und langlebigsten Projekte im Linux-Ökosystem markieren sollte. Lasst uns für einen kurzen Moment zurückblicken.

Es ist nicht nur ein gepimptes SLS, es ist das "Debian Linux Release". Ian Murdock, der selbst mit der vermutlich ersten Linux-Distribution unzufrieden war und beschlossen hat, die Sache selbst in die Hand zu nehmen, hätte sich womöglich nie erträumen können, dass sein "brand-new Linux release", wie er es damals nannte, irgendwann seinen 30. Geburtstag feiern würde.

Begründer eines Distributionszweiges

Im Laufe der Jahre hat Debian bewiesen, dass es mehr als nur ein übereifriger Rebell unter den Betriebssystemen ist. Es hat die Grundlage für viele andere Distributionen wie z. B. Ubuntu gelegt. Es hat die Freiheit und Offenheit verkörpert, die das Herzstück der Open-Source-Bewegung bilden. Es hat glaubhafte Alternativen zu proprietären Betriebssystemen aufgezeigt und Zweifler zum Schweigen gebracht. Auch, wenn der letzte Punkt in der öffentlichen Diskussion nicht ganz offensichtlich ist, sprechen die Zahlen für sich: Debian ist ein fester Bestandteil vieler produktiver Serversetups.

Mit der tief verwurzelten Philosophie, die sich im Debian-Gesellschaftsvertrag widerspiegelt, unterstreicht das Projekt seine kompromisslose Haltung zugunsten freier Software, auch wenn über die Jahre insgesamt eine gewisse Toleranz gegenüber nachinstallierbarer unfreier Software Einzug gehalten hat.

Debian ist heute wichtiger denn je, da die Distribution den Test of Time bestand und sich zu einer Alternative zu Enterprise-Distributionen gemausert hat. Stabilität und Kontinuität sind entscheidende Faktoren, denn Debian baut auf klassischen Releases auf, von denen - je nach Zählweise - bereits 20 erschienen sind. Die Release werden seit Version 1.1 nach Toy-Story-Charakteren bezeichnet. Debian ist ein Leuchtturm, ein einsamer Fels in der Brandung einer Welt, die zunehmend von Anbietern dominiert wird, welche Daten und Freiheiten der Nutzer nicht beachten und sie an ihre Plattformen binden.

In diesem Sinne, lasst uns auf 30 Jahre technologischer Alternativen anstoßen. Herzlichen Glückwunsch, Debian! Auf 30 weitere Jahre der Innovation und Unabhängigkeit.