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.

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.

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)

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.

Open-Source-Software nachhaltig zu entwickeln, wird immer schwieriger. Willkommen im Zeitalter von "Nur schauen, nicht anfassen" für kommerzielle Rivalen.

Das in San Francisco ansässige Softwareunternehmen HashiCorp, bekannt für seine Cloud-Tools wie Terraform, Vagrant oder Vault, ändert seine Lizenzbedingungen. In einer Ankündigung wird der Wechsel von der Mozilla Public License 2.0 zur Business Source License mit der Gewährleistung kontinuerlicher Investitionen des Unternehmens in seine Community begründet.

HashiCorp hält weiterhin daran fest, seinen Quellcode frei verfügbar zu machen. Allerdings gibt die BSL dem Unternehmen mehr Kontrolle darüber, wer den Code kommerziell nutzen darf. Mit anderen Worten, wer Software von HashiCorp produktiv nutzt und sie für ein Konkurrenzprodukt einsetzen möchte, ist von nun an nicht nur bösen Blicken, sondern auch rechtlichen Hürden ausgesetzt.

In guter Gesellschaft

Einige Unternehmen haben diesen Schritt bereits vollzogen und sind auf unfreie Lizenzmodelle umgestiegen. Couchbase, Sentry und MariaDB MaxScale sind einige Beispiele dafür. Dies wirft natürlich die Frage auf, ob wir uns von der Idee freier Open-Source-Software verabschieden müssen. Die Omnipräsenz der Cloud-Industrie, die seit den 2010er-Jahren sich großer Beliebtheit erfreut, droht ernsthaft, die FOSS-Welt zu destabilisieren.

Stellt dir vor, du hast einen reichen Obstgarten erschaffen, in dem jeder sich frei der Früchte bedienen kann. Größzügig lädst du alle ein, sich nach Belieben zu bedienen und empfiehlst ihnen, selber Bäume zu pflanzen oder die Saaten weiterzuverbreiten. Eines Tages bemerkt ihr jedoch, dass einige Gäste die Früchte einsacken, sie auf eigenen Märkten verkaufen und die Profite einsacken, ohne selbst an die Ursprungscommunity etwas zurückzugegeben. Klingt unfair? Genau das passiert momentan in der Open-Source-Welt.

Damit wird Open Source zwar nicht von Tisch gewischt, sondern in eine Richtung gelenkt, die den freien ungehinderten Austausch unabhängig von gewerblichen Interessen einschränkt. Konkret wackelt dabei das 6. Kriterium der Open-Source-Definition (OSD), das eine Unterscheidung nach Einsatzfeldern ausschließt.

HashiCorp betont, dass es sich weiterhin seiner Community, seinen Partnern und Kunden verpflichtet sieht. Nur die Zeit wird zeigen, ob diese Lizenzänderungen die richtigen Schritte auf dem Weg dorthin sind. Einerseits werden Möglichkeiten von Forks eingeschränkt, andererseits ist niemandem geholfen, wenn die Weiterentwicklung durch HashiCorp auf dem Spiel steht, nur, weil externe Akteure bezogen auf die Einnahmen sinnbildlich das Wasser abgraben. Die Leute, die Software entwickeln, müssen auch von etwas bezahlt werden.

Edit (20:25 Uhr): MariaDB setzt die BSL für MaxScale ein, nicht jedoch für die Datenbank MariaDB Server. Danke für den Hinweis, Jens.

Update (20:30 Uhr): Ggfs. werde ich mich mit der BSL noch einmal in einem gesonderten Artikel beschäftigen, aber ein kleines Detail ist hierbei vllt. noch erwähnenswert, um den Blick auf die Sache zu ändern. Die von HashiCorp verwendete Form der BSL setzt auf eine Art Embargozeit. Nach 4 Jahren der Veröffentlichung eines nach BSL lizenzierten Werkes in einer spezifischen Version, greift folgender Passus:

Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.

Als Change License wurde die MPL 2.0 festgelegt.

Das Team hinter dem bekannten Multimedia-Programm FFmpeg hat am 27.02.2023 die Version 6.0 freigegeben. Bei diesem Majorrelease gibt es Änderungen an der API, die trotzdem teils inkompatibel zu älteren Versionen sind und somit diesen Majorrelease nötig machen.

Da oftmals Informationen über die einzelnen Releases nicht direkt aufbereitet bereitgestellt werden, kann ich den Talk zu FFmpeg und VLS.js von Jean-Baptiste Kempf auf der FOSDEM 2023 am 4. Februar 2023 in Brüssel empfehlen. Die wichtigsten Änderungen gliedern sich laut ihm in CLI-Verbesserungen für Multithreading, RISC-V-Optimierungen, die Einbindung der AV1-Hardwareunterstützung bei Intel, Nvidia und AMD, optimiertem FFT-Code für SIMD bei x86 und ARM sowie einigen Änderungen an der API.

Das Projekt hat sich vorgenommen, eine Majorversion und bis zu zwei Minorversionen pro Jahr zu veröffentlichen. Dabei soll alle zwei Jahre die x.1-Version Long Term Support (LTS) von zwei Jahren erhalten, für alle anderen Versionen ist ein Support von einem Jahr angesetzt.

FFmpeg erschien 2000 und wurde von Fabrice Bellard initiiert, der auch für sein QEMU-Projekt bekannt ist, welches eine wichtige Rolle in der Virtualisierung auf Linux einnimmt. Das offizielle und stichwortorientierte Changelog ist im Git-Repository von FFmpeg verfügbar.

Was sich als Projekt vor zwei Jahren langsam abzeichnete, geht nun in die finale Umsetzung: der Linux-Kernel soll zukünftig nicht nur in der Programmiersprache C, sondern auch in Rust geschrieben sein. Während die Rust-Unterstützung noch die Aufnahme in Linux 6.0 knapp verpasst hat, soll es mit Linux 6.1 nun so weit sein. ZDNET berichtet von einer geplanten Aufnahme in die kommende Linux-Version:

The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1." (Steven Vaughan-Nichols, ZDNET.com, 19. September 2022)

Für die Implementierung ist das Projekt "Rust for Linux" zuständig (siehe Git-Repo auf GitHub). Federführend bei der Implementierung ist Miguel Ojeda, die Entwicklung wird von Unternehmen wie Google unterstützt und gesponsert.

Während C oft als "portable Assemblersprache" wahrgenommen wird, die viel Eigenverantwortung voraussetzt, abstrahiert Rust insbesondere das Speichermanagement zu gewissen Teilen über die Ownership-, Reference- und Borrowing-Konzepte weg. Die Sicherheit und Zuverlässigkeit des Linux-Kernels soll erhöht werden, indem bestimmte Programmierfehler konzeptionell verhindert werden.

Rust soll dabei den Kernel nur ergänzen und mittelfristig nicht ersetzen. Die Anstregungen, die das Rust-for-Linux-Projekt auf sich genommen hat, umfassen eine Infrastruktur und Umgebung, um Treiber in Rust für den Kernel entwickeln zu können.

Kurz notiert: das freie Routerbetriebssystem OPNsense ist am 28. Juli 2022 in Version 22.7 mit dem Codenamen „Powerful Panther“ erschienen. Ähnlich wie bei Ubuntu erscheinen hier zwei Major-Releases pro Kalenderjahr – Version 22.1 wurde dementsprechend im Januar diesen Jahres veröffentlicht.

Folgende Neuigkeiten bringt der Release mit:

• Das zugrundeliegende FreeBSD wird von Version 13 auf 13.1 aktualisiert.
• PHP, worauf große Teile der Nutzeroberfläche basieren, ist nun in Version 8.0, das PHP-MVC-Framework Phalcon in Version 5 verfügbar.
• Stacked VLANs (QinQ) nach IEEE 802.1ad (Wikipedia (en)) werden nun von OPNsense unterstützt.
• Unterstützung für Intel QuickAssist (QAT), ein Hardwarebeschleuniger, wird ermöglicht.
• Die Firewall erhält einen DDoS-Schutz, der auf SYN-Cookies (Wikipedia, D. J. Bernstein) zurückgreift.

Darüber hinaus wird die Abkehr von LibreSSL vorbereitet: so wird dies der letzte Release sein, der den OpenSSL-Fork alternativ anbietet. Im nächsten Großrelease wird ausschließlich OpenSSL unterstützt, Plugins müssen dementsprechend angepasst werden.

Die ausführliche Änderungsübersicht samt Prüfsummen und Mirroradressen ist hier verfügbar, die aktuelle Roadmap hier.

Kurz notiert: Vim hat diese Woche die Veröffentlichung eines neuen Major-Releases angekündigt. Die größte Änderung ist die Einführung von Vim 9 Script.

Bei Vim 9 Script handelt es sich um eine neue Skriptsprache für den bekannten textbaiserten Editor. Als Motivation geben die Entwickler zwei große Ziele an:

• Performance: Die Sprache wird kompiliert in Befehle, die effizient ausgeführt werden können und eine 10- bis 100-fach verkürzte Ausführungszeit ermöglichen.
• Syntax: Vim 9 Script orientiert sich syntaktisch an aktuellen, weit verbreiteten Programmiersprachen wie JavaScript, TypeScript und Java.

Insbesondere die Performanceziele haben den Weg für die Abwärtskompatibilität versperrt. Dabei wurde der Kompromiss gefunden, einerseits Vim 9 Script und andererseits „Legacy-Script“ (sprich: <= Vim 8) parallel zu unterstützen.

Weitere Hinweise zu Vim 9 Script sind unter :help vim9 verfügbar. Darüber hinaus wurden zahlreiche Bugs und Sicherheitslücken gefixt sowie die interne Testabdeckung erhöht. Letzteres soll zur Qualitätssicherung beitragen und die Robustheit erhöhen. Weitere Hinweise zu Neuerungen sind unter :help new-9 zu finden.

Kurz notiert: Arch Linux, die Linux-Distribution, die besonders durch ihr KISS-Prinzip bekannt geworden ist, feiert heute ihren 20. Geburtstag. Sie erblickte die Welt am 11. März 2002 mit dem Release der Version 0.1. Klassische (Major-)Releases gibt es bei Arch Linux nicht, da das Rolling-Release-Modell genutzt wird. Die "Versionen" fungieren dabei eher als Einstiegspunkt. Als Paketverwaltung kommt das eigene System pacman zum Einsatz. Bei Arch Linux stehen die Prinzipen der Einfachheit, Modernität, Benutzerorientierung, Vielseitigkeit und des Pragmatismus im Mittelpunkt. (siehe Wiki)

Wer mehr zur Geschichte von Arch Linux lernen will, kann einen Blick in das Arch Wiki sowie die heutigen Artikel auf Heise und LinuxNews werfen.

Ich selber habe Arch vor knapp 10 Jahren das erste Mal ausprobiert, damals noch mit initscripts und knapp vor der systemd-Umstellung – und bin bis heute der Distribution treu geblieben. Es wirkt, als würde die Zeit zu rasen beginnen, wenn man bedenkt, dass bei vielen, einschließlich mir, der Arch-Einstieg zeitlich näher am ersten Release zurückliegt, als am heutigen Tage.

In diesem Sinne: Happy Birthday, Arch Linux!