Während vergangene Woche die Nachrichten sich täglich überschlagen haben, ging es diese Woche etwas ruhiger zu – was aber nicht bedeutet, dass die Neuerungen weniger bahnbrechend sind. Die Woche im KI-Wochenrückblick.

ChatGPT Plugins

Wer die 17. Episode des Risikozone-Podcasts gehört hat, weiß, dass ich schon länger eine Erweiterung der "Text-KIs" skizziert habe, die das Sprachmodell auf die Textgenerierung beschränkt, aber die Informationsbeschaffung auf klassischem, deterministischem Weg umsetzt. Das habe aber nicht nur ich so gedacht, sondern auch die Forscher hinter Toolforge oder Entwickler hinter Werkzeugen wie LangChain oder ICortex. OpenAI hat ChatGPT mit den ChatGPT Plugins diese Woche seiner Text-KI genau diese Möglichkeit ebenfalls verpasst. Was als kleiner Schritt erscheint, dreht kurzfristig die KI-Nahrungskette um: während bisher die GPT-Modelle das Werkzeug waren, das in fertige Dienste integriert wurde, stellt ChatGPT nun das Tor in die Welt dar, das durch externe Informationen angereichert wird. So kann OpenAI nun z. B. einen Sachverhalt an WolframAlpha weiterleiten, ein Dienst, der (wissenschaftliche) Zusammenhänge präsizer verarbeiten kann und bereits seit langer Zeit die Grundlagen von Sprachassistenten darstellt. Weitere Informationen hierzu beschreibt Stephen Wolfram in seinem Blog. Aber auch Document Retreival, also das Durchsuchen der eigenen Datenberge, wird nun als Plugin unterstützt. Das dazugehörige GitHub-Repository chatgpt-retrieval-plugin trendet seit dem unentwegt.

Die Auswirkungen hinter dieser Neuerung werden maßgeblich durch die Bekanntheit von OpenAI verstärkt. Die Plugins setzen OpenAI jetzt in die Lage, Projekte und Startups, die lediglich ein Mashup, also eine Verschmelzung von GPT mit eigenen Informationen, angeboten haben, existentiell zu bedrohen. In diesem Aspekt ist OpenAI heute wie Google in den ersten Jahren: sie machen ein neues Feld besonders zugänglich, veröffentlichen in einer hohen Frequenz interessante Produkte – sind aber auch gefürchtet, weil sie die low-hanging fruits – die leichten Probleme – schnell lösen. Es bleibt weiterhin spannend.

Hello Dolly! Demokratisierung der Sprachmodelle

OpenAI wird zunehmend dafür kritisiert, die Entwicklung der neuen Sprachmodelle proprietär zu gestalten. Während GPT-2 noch einfach zugänglich war, ist GPT-3 nicht mehr einfach als Download verfügbar. Das ist natürlich für Forschung und Weiterentwicklung hinderlich, sichert für OpenAI aber nebenbei einen Wettbewerbsvorteil.

Die Antwort auf diesen "Missstand" kommt in diesen Tagen prompt: Databricks hat mit Hello Dolly an Alpaca aus letzter Woche angeknüpft und gezeigt, dass ein ChatGPT-ähnliches Modell auch auf Basis von GPT-J statt LLaMA (wie bei Alpaca) trainiert werden kann. GPT-J ist deshalb interessant, weil es noch aus der Zeit von vor zwei Jahren stammt, als Sprachmodelle offen bereitgestellt wurden.

Auch wenn GPT-J insgesamt über z. B. weniger Parameter verfügt, kann es trotzdem die hochwertigen Ergebnisse ermöglichen. Dabei zeichnet sich ab, dass die Methodik hinter Self-Instruct mächtig ist, was wiederum den Wettbewerbsvorteil der geheimen GPT-3-Gewichte relativiert.

Aber auch die Grundmodelle entwickeln sich weiter: so ist flan-ul2 von Google ein spannender Kandidat für ein solches Basismodell. flan-ul2 wurde erst Anfang des Monats veröffentlicht.

OpenAI stellt Codex-API ein

Realtiv geräuschlos stellte OpenAI offenbar die Zugänge zu den Codex-Modellen ein, hierzu gibt es nur Nutzerberichte. Im OpenAI Playground sind die Codex-Modelle auch nicht mehr anwählbar. Bemerkenswert ist hierbei die Vorwarnzeit, die lediglich wenige Tage betrug.

OpenAI Codex wurde 2021 veröffentlicht und war die spezielle Anpassung der GPT-3-Modelle für Code. Es bildete die Grundlage für den GitHub Copilot. GitHub hat in dieser Woche GitHub Copilot X vorgestellt, welcher nun auf GPT-4-Basis arbeitet. Die Einstellung von Codex ist hier schon fast folgerichtig, da OpenAI scheinbar ihr neues Modell GPT-4 als so allgemeingültig sieht, dass Textaufgaben und Codingprobleme über das gleiche System abgewickelt werden können.

Aber auch Codex bekommt Konkurrenz: Code Alpaca ist auch diese Woche erschienen und funktioniert ähnlich wie Alpaca, konzentriert sich aber speziell auf Codingprobleme. Die Web-Demo ist noch aktiv.

Kurz notiert für alle, die GitHub nutzen, um ihre Git-Repositories zu speichern. Laut einem Artikel auf dem GitHub-Blog sah sich das Team durch einen Leak eines RSA-SSH-Private-Keys diese Woche gezwungen, heute am 24. März 2023 um 05:00 UTC (06:00 Uhr deutscher Zeit) die Keys zu tauschen.

Da nach TOFU-Prinzip vom SSH-Client der Key gespeichert wird, der bei der ersten Nutzung verwendet wurde, werden nachträgliche Änderungen auf Host-Seite als Man-in-the-Middle-Angriff (MitM-Angriff) vermutet. Deswegen sollte der alte, nun komprimittierte Key aus der known_hosts entfernt werden. Wie das geht, habe ich auf dem Blog hier schon einmal beschrieben.

Bei der erneuten, jetzt wieder "erstmaligen" Verbindung mit github.com sollte in jeden Fall der neue Key unbedingt mit der verlinkten GitHub-Dokumentationsseite abgeglichen werden, da man sonst erst recht MitM-Angriffen ausgesetzt ist. In der Regel wird spätestens jetzt ein auf einem neuen Verfahren wie ed25519 basierender Host-Key angeboten, was man auch nutzen sollte.

Der KI-Wochenrückblick fasst die Nachrichten der Kalenderwoche 11 des Jahres 2023 zusammen. In dieser Woche gab es viele Neuigkeiten, darunter die Veröffentlichung von GPT-4, Midjourney 5, PyTorch 2.0 oder Alpaca.

Treue Leser des Blogs können sich noch an das Jahr 2018 und den Wochenrückblick erinnern. Über ein halbes Jahr habe ich im Wochentakt das Geschehen der Woche zusammengefasst. Der Wochenrückblick wurde nach kurzer Zeit wieder eingestellt und sollte auch nur als Experiment dienen.

Im Jahr 2023 wird allerdings der Wochenrückblick aus einem anderen Blickwinkel wieder relevant. Wir erleben momentan etwas, was mich an die Erfindung des iPhones erinnert: eine neue Technologie ist da und man möchte den ganzen Tag die Funktionalität ausprobieren. Dies fing bereits 2022 mit GPT-3 und DALL-E an setzt sich nun mit Stable Diffusion, ChatGPT und den ganzen neuen Modellen fort.

Um die Flut an Informationen zu sortieren, möchte ich die Gelegenheit nutzen und im KI-Wochenrückblick das Geschehen der Woche aufarbeiten und kurz zusammenfassen.

GPT-4 erschienen

Den Anfang macht ganz klar OpenAI mit GPT-4. Um die neue Version des bekannten Large Language Models (LLM) gab es schon seit einiger Zeit einen gewissen Hype. Am Dienstag war es dann soweit: OpenAI hat GPT-4 veröffentlicht. In einem Demo-Livestream wurden die Möglichkeiten vorgestellt. GPT-4 soll multimodal sein und neben Text auch Bilder verarbeiten können. Die Anzahl der Tokens steigt von 2048 auf 32k Tokens, was in etwa 25.000 Wörtern entspricht. Eine Eingabe kann also deutlich länger sein als bisher.

Das mit Spannung erwartete Paper, welches jetzt auf arxiv.org liegt, bietet allerdings recht wenig Einblicke in die Funktionsweise. Hier wurde der Fokus besonders auf Vergleiche bei standardisierten Tests gelegt, Details zur Architektur wurden nicht verraten. Diese Politik enttäuscht teilweise die Forschungswelt und wird bisher mit dem Konkurrenzdruck begründet. (Blogartikel von Dienstag)

Midjourney V5 Alpha veröffentlicht

Bei den Text-zu-Bild-Wandlern gibt es auch Neuigkeiten. Midjourney ist als Alpha in Version 5 verfügbar, wie das Team auf Twitter berichtet. Mit dem neuen Release werden die Bilder deutlich realistischer und die Qualitätssteigerungen werden sichtbar.

Midjorney ist allerdings, im Gegensatz zu OpenAI-Produkten, aktuell nicht als API verfügbar und kann nur teils kostenpflichtig über den Discord-Server erreicht werden.

ViperGPT: Visuelle Inferenz mittels Python-Ausführung

Eines meiner persönlichen Highlights der Woche ist die Vorstellung von ViperGPT und dem dazugehörigen Paper. Es geht ein Problem an, welches insbesondere bei Bild-Tasks präsent ist: während jeweils die Erkennung von Objekten oder die Codegenerierung für ein Problem relativ zuverlässig sind, ist die Kombination aus beidem fehleranfällig.

Beispiel: wir haben ein Bild mit verschiedenen Pizzastücken und Personen vorliegen. Die Frage "Wie viele Stücke könnte jede Person erhalten, wenn die Pizza fair aufgeteilt wird?" ist schwierig zu beantworten, wenn wir einen End-to-End-Ansatz fahren. ViperGPT wählt allerdings einen anderen Ansatz: hier wird ein Python-Programm generiert, welches Platzhalter für die eigentlichen Image-Recognition-Tasks im Rahmen von speziellen find()-Funktionsaufrufen lässt. Die eigentliche Aufteilungberechnung pizzastueckzahl // personenanzahl wird vom Codegenerator-Modell zwar formuliert, dann aber ganz normal deterministisch in Python auf einer CPU ausgeführt. Somit wird einerseits das Modell erklärbarer und andererseits auch deterministischer.

Ich freue mich schon auf den Code, um das Verfahren auszuprobieren. Wenn das funktioniert, lassen sich in meinen Augen die Vorteile unscharfer Large Language Models und präsizer Computerberechnungen besser kombinieren.

PyTorch 2.0 erschienen

PyTorch ist ein wichtiger Baustein in der ML-Forschung, da es als wichtiges Framework und TensorFlow-Konkurrent die Modelle erst implementierbar und trainierbar macht. Umso spannender ist es, dass hier eine neue Version erschienen ist.

In Version 2.0 sind allerdings glücklicherweise keine substantiellen Breaking Changes zu erwarten, es ist eine umgebrandete Version 1.14. Hinzu gekommen ist insbesondere torch.compile(), sodass Modelle vorkompiliert werden können und nicht mehr zwangsläufig im "eager mode" arbeiten müssen. (Blogartikel von Samstag)

Alpaca: Do-it-yourself GPT?

Ein großer Nachteil der aktuellen KI-Forschung liegt in der Verfügbarkeit der Modelle. Dabei müssen wir zwischen Modellen und Modellen unterscheiden – leider wird beides oft mit dem gleichen Namen bezeichnen. Modelle können einerseits die Architektur beschreiben (GPT-3, LLaMA, AlexNet, ...), andererseits aber auch die Architektur plus die dazugehörigen Gewichte (= das Herzstück für den Einsatz eines Modells) bedeuten. Die Gewichte sind das Ergebnis des Trainings.

Die Architektur wird meist offengelegt (in GPT-4 jetzt nicht mehr, wie wir gesehen haben), die Gewichte sind oft unter Verschluss, sind aber die Voraussetzung für den Betrieb eines vortrainierten Modells. LLMs wie GPT-4 oder PaLM sind prioprietär, Meta beschreitet mit LLaMA einen Mittelweg mit einer restriktiven Lizenz und andere Modelle wie die Spracherkennung Whisper sind komplett offen.

Um nun aber zügig ein lauffähiges, lokales LLM aufzubauen, haben die Stanford-Forscher mit Alpaca einen Trick angewandt. Sie nehmen das LLaMA-Modell und führen mittels Instructions, die mit ChatGPT synthetisiert werden, über das Self-Instruct-Verfahren ein Fine-Tuning durch. Herauskommen soll ein Modell, welches mit GPT-3 konkurrieren kann, aber unter 600 USD im Training gekostet hat. Das ist für bisherige Verhältnisse sehr billig.

Das Modell gibt es noch nicht zum Download, hier möchte das Alpaca-Team in Verhandlung mit Meta treten. Die Auswirkungen wären tatsächlich enorm, da einerseits die Entwicklungen lokal nachvollziehbar werden (für die Wissenschaft unerlässlich), andererseits aber der Alleinstellungswert von LLM-Providern sinkt, wenn ein anderes Modell einfach ihr Modell imitieren kann.

Weitere Neuigkeiten

• Microsoft 365 Copilot hält Einzug in Office
  Dieser Schritt war aus meiner Sicht seit dem 10 Mrd.-Investment erwartbar und wird nun umgesetzt. Effektiv wird dadurch ChatGPT direkt in Office nutzbar.
• Google führt KI-Systeme in Google Workspace ein
  Google zieht nach und bietet ähnliche Funktionen in den eigenen Produkten mit den eigenen Modellen an. Auch hier geht es darum, das Prompting innerhalb der Dokumente zu ermöglichen. Durch die enge Einbindung von Gmail in die Business-Suite können aber auch über die Schnittstellen z. B. E-Mail-Vorlagen schnell modifiziert werden.

Das Team hinter PyTorch hat am 15. März 2023 Version 2.0 des Machine-Learning-Frameworks veröffentlicht. PyTorch 2.0 bringt zahlreiche Verbesserungen und Neuerungen mit sich. Zu den Highlights zählen die Beta-Version der torch.compile()-API und die verbesserte Integration von torch.nn.functional.

Neben der bewährten Entwicklung über den „eager mode“ gibt es nun die Möglichkeit, Modelle über den Befehl torch.compile zu kompilieren. Diese Änderung ermöglicht Leistungssteigerungen und ist vollständig abwärtskompatibel zur vorherigen Version. Der Versionssprung auf 2.x dient eher symbolischer Natur – ansonsten würde es eher einer Version 1.14 entsprechen.

Die Integration ist einfach und erfordert lediglich die Installation einer Nightly-Version und die Optimierung des Modells mit einer einzigen Codezeile:

model = torch.compile(model)

Version 2.0 bietet Leistungssteigerungen sowohl beim Training als auch bei der Inferenz und ist insbesondere für neuere GPU-Generationen optimiert. Neben der Hauptversion werden auch Beta-Updates für PyTorch-Domain-Bibliotheken wie TorchAudio, TorchVision und TorchText veröffentlicht. Weitere Informationen zu den Änderungen bei den Domain-Bibliotheken sind in einer gesonderten Pressemitteilung verfügbar. Für PyTorch 2.0 selber ist eine eigene Get-Started-Seite bereitgestellt worden.

PyTorch ist ein Machine-Learning-Framework unter der BSD-3-Lizenz, welches ursprünglich von Facebook AI (heute: Meta AI) 2016 veröffentlicht wurde und nun unter der Schirmherrschaft der Linux Foundation steht. Es baut auf das zwischenzeitlich eingestellte Torch auf, welches 2002 am EPFL in Lausanne in der Schweiz entstand. Heute steht PyTorch in Konkurrenz zu TensorFlow von Google und wird von verschiedenen Anwendungen eingesetzt, darunter Hugging Face Transformers, OpenAI Whisper oder der Tesla Autopilot.

Kurz notiert: soeben hat OpenAI GPT-4 angekündigt. Das Modell ist in ChatGPT+ verfügbar, API-Nutzer können sich bereits auf einer Warteliste eintragen. Neuerungen sind u. a. die größere Anzahl an Tokens und die Fähigkeiten, auch Grafiken zu verarbeiten – das Modell wird somit multimodal.

Die Fähigkeiten werden heute in einem Livestream um 1 PM PT bzw. 21 Uhr deutscher Zeit vorgestellt. Der Livestream ist auf YouTube verfügbar.

Das Paper zu GPT-4 wurde ebenso veröffentlicht.

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.

Wie GitHub bereits im Juni 2022 verlauten ließ, wurde der Editor Atom eingestellt. Dabei wurde am 15. Dezember 2022 das Repository archiviert und die Entwicklung somit vollständig beendet. Atom erschien im Jahr 2014 und wurde direkt durch GitHub entwickelt und stellte eine Alternative zu Editoren wie Sublime Text oder Notepad++ dar. Der Editor hat dabei nachhaltig die Welt der Desktop-Anwendungen verändert.

Der Grund hierfür liegt in der Basis, die anfangs noch Atom Shell hieß, aber später in Electron umbenannt wurde – ein Begriff, den viele sicherlich kennen werden. Electron wiederum nutzt Chromium als Basis, sodass die Entwicklung plattformunabhängiger Anwendungen ermöglicht wird, bei denen die eigentliche Anwendung lediglich innerhalb der Chromium-Browserinstanz ausgeführt wird.

Electron

Electron wird dabei kontrovers diskutiert. Es fällt auf der einen Seite der Ressourcenverbrauch auf, der entsteht, wenn mehrere Electron-Anwendungen mehrere Chromium-Browserinstanzen ausführen, die dann den RAM belagern. Auch sind Anwendungen nicht gerade klein – so ist eine Größe von über 100 MB selbst für kleinere Anwendungen nicht unüblich. Nicht allzuletzt wird der Kern der Anwendung auch in JavaScript und mit Paketen aus dem npm-Ökosystem ausgeführt. All das sind Faktoren, die zu einer hohen Komplexität und regelmäßigen Sicherheitsaktualisierungen führen, welche nicht außer Acht gelassen werden dürfen. Auf der anderen Seite stellt Electron aber eine Alternative zu verschiedensten Desktop-Frameworks wie Qt oder wxWidgets dar, steht unter der MIT-Lizenz und ermöglicht dank HTML, CSS und JavaScript eine mitunter einfachere Entwicklung von grafisch hochwertigen Anwendungen. Ob die Vorteile die Nachteile aufwiegen, bleibt dem Einzelfall überlassen.

Electron wird von Anwendungen wie Discord, Microsoft Teams oder auch Microsoft Visual Studio Code eingesetzt. Letztere Anwendung wird auch Atom beerben, da es nach dem Aufkauf von GitHub durch Microsoft nur eine Frage der Zeit war, bis einer der beiden Editoren weichen muss. GitHub selber möchte sich mit der Entscheidung vor allem auf die GitHub Codespaces konzentrieren, die Visual Studio Code in den Webbrowser bringen.

Mittlerweile gibt es im übrigen auch Alternativen zu Electron. Eine davon ist Tauri. Das Rust-Framework bietet dabei ähnliche Funktionen, baut intern aber nicht auf Chromium, sondern auf den jeweiligen WebView der OS-Plattform auf. Hier ist ein kurzer Einführungsartikel zu Tauri zu finden.

Aktueller Sicherheitshinweise zu Atom

Obgleich ich diesen Artikel deutlich früher schreiben wollte, gibt es heute einen wichtigen Anlass dazu: wer Atom noch einsetzt, sollte diesen Artikel beachten, da GitHub einige Zertifikate für Atom und GitHub Desktop zurückziehen musste und ggfs. ein Downgrade der Versionen erforderlich ist.

Der Jahreswechsel steht bevor und ich möchte mich an dieser Stelle bei allen Lesern bedanken, die mich auch dieses Jahr auf meinem Blog begleitet haben. 16 Artikel habe ich dieses Jahr auf diesem Blog veröffentlicht, womit ich weiterhin die übliche Frequenz an Artikel auf diesem Blog halten konnte.

Das Highlight in diesem Jahr war der Start des Risikozone-Podcasts, der seit September regelmäßig läuft und Themen der IT-Sicherheit in ca. 45-minütigen Episoden behandelt. Eine besondere Ausgabe war dabei gleich die Sonderepisode 6, in der Sönke Huster seine entdeckten Lücken im Linux-WLAN-Stack uns erläutert hat.

Ich wünsche euch allen einen guten Rutsch ins neue Jahr und hoffe, dass ihr noch eine schöne Silvesternacht verbringen werdet. Lassen wir gemeinsam das Jahr 2022 hinter uns und starten mit voller Vorfreude und Zielen ins Jahr 2023.

Viel Glück, Gesundheit und Erfolg!

Viele der Technologien, die wir heutzutage einsetzen, haben eine lange Geschichte hinter sich. Moderne Ansätze, sie nachzurüsten, können in bestimmten Szenarien jedoch unangenehme Auswirkungen haben. Ein kleines Beispiel möchte ich euch heute vorstellen.

Craig Younkins hat in seinem Blog auf Medium ein kurzes Szenario beschrieben, das verschlüsseltes DNS (DoH/DoT) und NTP involviert. Normalerweise gibt es bei so einem Setup wenig Probleme: der Client synchronisiert seine Zeit über NTP, kann Abweichungen ausgleichen und seine DNS-Anfragen über TLS-verschlüsselte Verbindungen abwickeln. Dabei hat der Client jederzeit seine vertrauenswürdigen Zertifikate lokal gespeichert, ebenso die Standardserver für NTP, die üblicherweise durch einen Hostname nach dem Muster *.pool.ntp.org adressiert werden.

Das Problem

Der Fallstrick: vergisst der Client die Zeit komplett, kann er in einem Deadlock landen und gegebenenfalls die Zeit nicht mehr synchronisieren. So ein Szenario kann auftreten, wenn ein System ausgeschaltet wurde und keine Real-Time-Clock in der Hardware verbaut wurde, die über eine eigene Batterieversorgung (i. d. R. Knopfzelle) verfügt. Bei einigen günstigen Routern bzw. IoT-Geräten wie dem Raspberry Pi ist das der Fall.

Findet das System keinen Anhaltspunkt über die aktuelle Zeit, so startet es, je nach Implementierung, meist beim Unix-Timestamp 1 bzw. am 01.01.1970. Dies kann jedoch in Verbindung mit TLS eine gefährliche Wirkung entfalten, da für die Zertifikatsvalidierung auf das aktuelle Datum zurückgegriffen wird – schließlich verfügen die meisten Zertifikate über einen festen Gültigkeitszeitraum, der nur wenige Monate umfasst.

Das Ergebnis: alle mit TLS abgewickelten DNS-Anfragen über die NTP-Server schlagen fehl. Dabei ist hervorzuheben, dass NTP selber unverschlüsselt weiterhin abläuft, es können lediglich die IP-Adressen der Server nicht ermittelt werden.

Lösungen

Damit soetwas nicht passiert, können Administratoren auf verschiedene Art und Weise vorbeugen. Eine erste Möglichkeit wäre, wie im Artikel beschrieben, das Hinterlegen von IP-Adressen im NTP-Client. Damit umgeht man DoH/DoT und kann direkt mit der NTP-Synchronisation fortfahren. Nachteil dieser Variante ist jedoch, dass es einerseits nur wenige NTP-Server mit wirklich statischen Adressen gibt (einer der wenigen Anbieter ist z. B. die NIST) und andererseits NTP generell eher auf Hostnames arbeitet, um z. B. einen Lastausgleich sicherzustellen.

Die zweite Variante wäre der Einsatz spezieller DHCP-Optionen wie Option 42, mit der beim Bezug der Netzwerkkonfiguration auch durch den DHCP-Server bestimmte IPv4-Adressen empfohlen werden können. In der Regel handelt es sich um lokale IPv4-Adressen, wenn lokal ein eigener NTP-Server betrieben wird, der seine Zeit mit höherrangigen Servern wiederum synchronisiert. DHCPv6 verfügt mit Option 56 über ein Äquivalent. (Q, RFC 2132 sec. 8.3., RFC 5908)

Es gibt allerdings auch spannendere Methoden: so ist der Ansatz von tlsdate, die Zeit über den TLS-Handshake von Internetdiensten wie Google oder Wikipedia zu extrahieren. Darüber hinaus wird momentan bei der IETF die Entwicklung von roughtime vorangetrieben, das hierfür ein eigenes kryptographisches Protokoll einsetzt. (Q, draft-ietf-ntp-roughtime-07, Artikel von Cloudflare)

Wer ein Dateisystem wie ext4 nutzt, findet darüber hinaus im Superblock aus dem vergangenen Mount hilfreiche Zeitangaben. Diese mount time und write time werden nämlich in der Regel bei jedem Mount und Schreibvorgang gesetzt und können als Anhaltspunkt für die Systemzeit des vergangenen Starts dienen - genug, um bei regelmäßig verwendeten Systemen immerhin die DoH-Anfrage für die initiale NTP-Namensauflösung abzuwickeln. (Q)

Fazit

Verschiedene komplexe Komponenten wie DoH/DoT und NTP können bei bestimmten Randbedingungen zu Situationen führen, die man bei der Erstkonfiguration vermutlich nicht vor Augen hatte. Wer jedoch mit dafür anfälligen Systemen ohne Real-Time-Clock arbeitet, kann auf verschiedene Strategien zur Abhilfe setzen: einerseits können Anhaltspunkte für die Zeit aus dem vergangenen Start gesucht werden oder zunehmend Protokolle genutzt werden, die genau dieses Problem adressieren.

Man pages formen auf heutigen unixoiden Systeme eine entscheidende Säule. Sie sind das integrierte Handbuch, das einerseits die Kommandos erklärt und andererseits auch eine Referenz für die jeweiligen C-Bibliotheken und Syscalls darstellt. Wer also Anwendungsentwicklung auf Linux o. ä. betreibt und dabei insbesondere auf C zurückgreift, kommt an man pages schwer vorbei. Dabei bieten sie einige Vorteile: sie sind lokal verfügbar, nach einem konsistenten Schema aufgebaut und erklären die verschiedenen Befehle und Schnittstellen. Man pages sind tatsächlich so unverzichtbar, dass jeder C-Entwickler sie regelmäßig konsultieren sollte. Immerhin werden hier nicht nur die Kommandos und ihre Wirkungsweise erklärt, sondern auch auf Seiteneffekte und Fehlermeldungen eingegangen. Dies ist essentiell, da viele Bestätigungen oder Fehler nur über Rückgabewerte kommuniziert und im letzteren Fall über spezielle (globale) Variablen wie errno erläutert werden.

In diesem Zusammenhang ist es wichtig, diese man pages aufzusuchen und durchsuchen zu können. Den ersteren Teil könnt ihr im Artikel von Ralf Hersel auf gnulinux.ch nachlesen, das konkrete durchsuchen aller man pages möchte ich heute in diesem Artikel kurz betrachten.

Wir können mit dem man-Kommando alle Beschreibungen der man pages (-k, apropos) und auch den gesamten Inhalt der man pages (-K) durchsuchen.

Beschreibungen durchsuchen

Für den heutigen Fall möchten wir uns damit beschäftigen, wie wir ein Programm beenden können. Grundsätzlich kann ein exit vielfältig aussehen: wir können ihn auf der Shell durchführen, exit könnte aber auch einen Syscall oder eine C-Funktion aus der Standardbibliothek bezeichnen. Wenn wir schon dabei sind: exits gibts natürlich auch auf der pthread-Ebene, wir können aber auch eine Funktion registrieren, die bei einem normalen exit aufgerufen werden soll. Kurzum: wir müssen uns vorher erst einmal informieren, was wir überhaupt finden können, um dann die richtige man page aufzurufen. Diese Suche geht mit folgenden Kommandos, die auf das gleiche Ergebnis kommen:

man -k exit
apropos exit

Uns wird eine Liste aller man pages zusammengestellt, die exit im Namen oder der Kurzbeschreibung enthalten. Hier haben wir die Möglichkeit, die richtige Handbuchseite aufzufinden, um dann z. B. exit(0) im C-Programm aufzurufen.

Komplette man pages durchsuchen

Manchmal kann es allerdings passieren, dass wir zu einem gegebenen Suchbegriff über apropos nicht fündig werden. Dann müssen wir den kompletten Inhalt der man pages einbeziehen, weil der gesuchte Begriff mitunter in den detaillierten Beschreibungen erst zu finden ist.

Um bei unserem Beispiel zu bleiben, möchten wir weitere Informationen über die Konstante EXIT_SUCCESS finden, die oft anstelle von 0 als exit-Code benutzt wird. Hier müssen wir alle man pages nun durchsuchen, weil es keine man page dazu gibt, die diese Konstante in der Kurzbeschreibung erwähnt.

Wir nutzen:

man -K EXIT_SUCCESS

Nun werden alle man pages durchsucht, was zu vielen Ergebnissen führen kann. Das erste Ergebnis wird automatisch geöffnet (bei mir ist es das certtool), das mag uns aber nicht zufriedenstellen.

Wir können den Pager über q verlassen und nun durch die anderen Ergebnisse uns durcharbeiten. <Enter> führt zur Anzeige der man page, <Strg + D> zum Überspringen des Suchergebnisses und <Strl + C > zum Abbruch der Suche.

Bei dieser konkreten Konstante müssen wir uns Beispiele und Hinweise anschauen, um die Verwendung zu verstehen, deswegen kann es sein, dass man sich mehrere man pages anschauen muss, die thematisch dazu passen.

Zusammenfassung

Man pages sind das klassische Offline-Handbuch von unixoiden Systemen. Wenn man nicht sofort weiß, wo man etwas suchen soll, kann man die beiden Suchfunktionen (Beschreibung, Volltext) nutzen, die das man-Kommando bereitstellt. Weitere Informationen hierzu sind unter man man (man(1)) verfügbar.

Am Samstag, dem 15.10.2022 wurden neue Versionen des Linux-Kernels veröffentlicht, darunter 6.0.2, 5.19.16 und 5.15.74. Mit diesen Versionen werden verschiedene Sicherheitslücken geschlossen, die der Sicherheitsforscher Sönke Huster aufgedeckt hat.

Konkret geht es hierbei um den WLAN-Stack. Er ist im Kernel notwendig, um drahtlose Netzwerkzugriffe zu ermöglichen. Verschiedene Treiber unterstützen die verschiedenen WLAN-Chips, welche die Kommunikation zur Außenwelt bereitstellen. Trotzdem teilen sich die Treiber eine gemeinsame Infrastruktur – und in dieser Infrastruktur wurden einige Fehler gefunden.

Den Fehlern wurden verschiedene CVEs zugewiesen. Konkret geht es um:

• CVE-2022-41674: fix u8 overflow in cfg80211_update_notlisted_nontrans
  • (max 256 byte overwrite) (RCE)
• CVE-2022-42719: wifi: mac80211: fix MBSSID parsing use-after-free
  • use after free condition (RCE)
• CVE-2022-42720: wifi: cfg80211: fix BSS refcounting bugs ref counting
  • use-after-free possibilities (RCE)
• CVE-2022-42721: wifi: cfg80211: avoid nontransmitted BSS list corruption
  • list corruption, according to Johannes will however just make it endless loop (DOS)
• CVE-2022-42722: wifi: mac80211: fix crash in beacon protection for P2P-device
  • NULL ptr dereference crash (DOS)

Besonders ins Auge fällt eine Lücke, die einen Buffer Overflow beim Scannen verschiedener WLAN-Netze zur Anzeige verfügbarer Netze ermöglicht. Die Brisanz entsteht dadurch, dass die Lücke interaktionslos (Zero Click) ausgenutzt werden kann: dadurch, dass der Scan automatisch abläuft und ein Angreifer bösartige WLAN-Frames ausstrahlen kann, die dann automatisch verarbeitet werden, ist kein aktives Klicken auf eine ausführbare Datei nötig. Glücklicherweise existiert zum aktuellen Zeitpunkt noch kein bekannter Exploit, der diese Lücke bösartig ausnutzt. Die Updates sollten trotzdem eingespielt werden, um hier nicht unnötig einem Risiko ausgesetzt zu sein.

Weitere Details und die Geschichte hinter der Lücke gibt es in der Sonderepisode 6 meines Risikozone-Podcasts. In dieser Episode führen Prof. Dr. Andreas Noack und ich ein Interview mit Sönke Huster, dem Entdecker der Lücke. Sönke erklärt in der Episode die Lücken und erläutert, wie er sie entdeckt und gemeldet hat. Insbesondere der Disclosureprozess wird Thema der Episode sein, da hier die Arbeitsweise in einem Open-Source-Projekt wie dem Linux-Kernel bei so einem Vorfall deutlich wird. Die Podcastepisode ist ab sofort auf risikozone.de/rz006 als Audio und – extra für diese Episode – auf YouTube als Video verfügbar. Sie ist aufgrund des besonderen Themas mit etwa 90 Minuten etwas länger als die üblichen 40 Minuten, aber dennoch für den Ausklang des Wochenendes sehr empfehlenswert.

Konkrete Informationen zur Lücke in der E-Mail von Sönke verfügbar, LWN.net hatte bereits am Donnerstag darüber berichtet. Mittlerweile hat auch das BSI eine Warnung aufgrund der CVEs herausgegeben.

Der Standard der Standards: Gestern wurde der Smart-Home-Standard Matter in Version 1.0 von der Connectivity Standards Alliance (CSA) veröffentlicht. Er soll Licht ins Dunkle bringen und das Standard-Chaos unter den Smart-Home-Geräten auflösen. Reflexartig werden viele meiner Leser jetzt die Zahl 927 in die Tastatur tippen, aber ich werde mich erstmal überraschen lassen, was sich ergibt. Vielleicht ist es nicht "yet another standard", sondern tatsächlich eine Verbesserung. Zudem haben sich viele große Smart-Home-Anbieter in der Allianz zusammengeschlossen, um diese Harmonisierung durchzuführen – bevor es die Regulatoren tun, wie wir gerade erst mit USB-C gesehen haben.

Ich werde mich in den nächsten Wochen genauer mit Matter beschäftigen und schauen, was sich dazu erforschen lässt. Auch die Security-Aspekte werden dabei relevant werden. Was ich aber ausgesprochen schade finde, ist, dass die Spezifikation (also der Kern des Standards), gar nicht öffentlich ist, wie sich in der Wikipedia lesen lässt:

Version 1.0 of the specification was published 30 September 2022. The Matter specification is provided at no charge upon request after providing full name, company name, email address and consenting to their privacy policy, but cannot be redistributed without permission from CSA.

Das steht natürlich im Kontrast zu anderen Standards wie QUIC, die einfach online und ohne Registrierung vom RFC Editor abgefragt werden können. Ich werde mir wohl für meine Arbeit einen Zugang diesbezüglich holen, kann dann aber im Blog höchstwahrscheinlich nicht mehr auf die Details aus der Spezifikation eingehen. Im Grunde ist es dann ähnlich wie mit Standards von z. B. der IEEE, aber die Chance der besseren Zugänglichkeit des Standards wurde offenbar nicht genutzt. Deswegen ein Blogartikel im Voraus mit meinen Hypothesen und Erwartungen.

Was ich bereits gut finde

Es gibt viele Standards, die sich in den vergangenen Jahren im IoT-Umfeld entwickelt haben. Das hat für eigene Anwendungen natürlich einen Einfluss auf den Layer 7 (Application), also die konkrete Implementierung von Anwendungen: wenn sich der Lichtschalter anders als der Heizkörperthermostat verhält (z. B. das eine System bietet nur HTTP REST auf einer Cloud an, das andere erwartet lokales MQTT), dann bedeutet das einen Mehraufwand, der verhindert werden könnte, wenn man sich auf ein Interface einigt. Aber bevor wir über Layer 7 überhaupt nachdenken können, muss Layer 3 (Network) geklärt sein. In beiden Fällen gibt Matter Vorgaben, wie in Abbildung 1 dargestellt: Layer 7 wird durch den Standard selber beschrieben und als Layer 3 wird IPv6 erwartet. Das ist spannend, da sich hier – sofern technisch dem Zugriff keine Schranken gesetzt werden – damit eine Integration in Heim- und Unternehmensnetze auf klassischen Standards möglich ist. Als Layer 1 bzw. 2 können Ethernet, Wi-Fi, Thread (IEEE 802.15.4), IPv6 for Bluetooth Low Energy, u. v. m. dienen.

Der Einsatz von IPv6 muss allerdings auch technisch implementiert werden: so müssen nicht nur Router und Firewall IPv6 generell unterstützen, sondern die (hoffentlich dedizierten) IPv6-Netze müssen auch bereitgestellt werden. Ob und in welchem Umfang die lokalen Unique Local Addresses (ULAs) nach RFC 1884 eingesetzt werden können, weiß ich zum aktuellen Zeitpunkt noch nicht. Begrüßenswert ist es in jedem Fall.

Warum rede ich überhaupt von ULA? Da IPv6 nativ kein NAT kennt, dürfte man doch damit gar nicht ins Internet kommen? Ja genau, das muss man bei Matter auch nicht, da der Standard auch lokal und ohne Cloud laufen kann. Somit müssen Schaltbefehle nicht umständlich über das Internet geroutet werden, sondern können den Weg direkt im Heim- oder Unternehmensnetz laufen. Auch das ist eine gute Sache, da so eine Zugriffskontrolle auf Vermittlungsebene in der Organisation durchgesetzt werden kann und man nicht vor verschlüsselten REST-Nachrichten steht.

Apropos Verschlüsselung, an die wurde auch gedacht. So sollen die ausgetauschten Nachrichten signiert und verschlüsselt werden können, ein Aspekt, der vielen Smart-Home-Geräten bisher fehlt.

Matter stellt weiterhin nicht nur eine Spezifikation, sondern auch ein SDK bereit. Dieses ist tatsächlich Open Source und unter der Apache-2.0-Lizenz auf GitHub verfügbar.

Wo ich noch genauer nachhaken werde

Grundsätzlich stellt sich die Frage der Zugänglichkeit zum System: es bleibt zu hoffen, dass die Geräte nicht nur mit fremden Smart-Home-Anwendungen, sondern auch mit den eigenen Smart-Home-Anwendungen kommunizieren können. Wenn ich mir ein Script schreiben will, das Steckdosen schaltet oder Heizthermostate einstellt, brauche ich einen standardisierten, nicht-diskriminierenden Zugriff. Konkret meine ich damit, dass das System – solange ich mich standardkonform verhalte – nicht danach unterscheiden (= diskriminieren) soll, ob ich ein anderes zertifiziertes Smart-Home-Device bzw. eine solche Anwendung bin, oder nicht. Wenn sich ein Ökosystem entwickelt, das zwar Institutionen freien Zugriff gewährt, aber interessierte Einzelpersonen kategorisch ausschließt, ist in der Frage dem fortgeschrittenen Smart-Home-Entwickler bzw. -Anwender wenig geholfen.

Auch der Punkt mit dem Distributed Compliance Ledger (vgl. diesen Artikel von Espressif, den ESP32-Machern, dazu) muss kritisch hinterfragt werden: die Funktionsweise liest sich wie die einer klassischen PKI, vor allem, da die CSA offenbar sowieso Top-Down organisiert ist. Vielen wird sowieso beim Begriff permissioned blockchain der Kamm hochgehen, da eine Blockchain-Datenbank mit Zugriffsverwaltung dem Urgedanken des P2P-Netzwerkes mit der gemeinsamen Konsensfindung zuwiderläuft. Bisher konnte ich diesbezüglich nur ein GitHub-Projekt der ZigBee-Alliance finden, bei dem als Grundlage die Cosmos-Blockchain läuft.

Von der Kritik deutlich zu trennen ist aber der lobenswerte Umstand, dass Firmware-Downloads überhaupt integritätsgeschützt und authentifiziert werden. Sollte es aber tatsächlich so sein, dass es sich beim DCL um eine PKI handelt, über die eine Blockchain gestülpt wurde, kann man sich die Blockchain mitunter gleich sparen.

Abschließend ist auch Kompatibilität ein Punkt: so sollen einige bereits existierende Smart-Home-Geräte zukünftig Matter-Fähigkeiten über ein Firmware-Update erhalten können. Mit Matter 2.0 stellt sich aber auch früher oder später die Frage, ob Matter sich als auf- und abwärtskompatibel erweisen wird: Können bestehende Matter-1.0-Geräte geupdated werden und wie gehen 2.0er-Geräte mit 1.0-Geräten um? Müssen diese mitunter neu gekauft werden?

Wofür ich einen Smart-Home-Standard brauche

Hier habe ich aktuell ein Projekt, das ich bei Gelegenheit implementieren möchte: so soll sich mein Heizthermostat an meinem Kalender orientieren. Wenn ich mir in meinem CalDAV-unterstützenden Kalender einen Außer-Haus-Termin setze, soll die Temperatur abgesenkt werden. Hierzu brauche ich ein Script auf einem Server und ein Heizthermostat. Dieses Heizthermostat selber soll nun aber nicht in meinen Kalender schauen können (Warum auch? Ich habe mehrere Kalender, die in Kombination betrachtet werden müssen.), sondern durch mein Script lokal angesteuert werden. Dieses Script arbeitet dann auf einer Workstation oder einem Raspberry Pi.

Somit managed das Script dynamisch die Heiztemperatur (Input: CalDAV-Kalender) und soll das den Aktoren, also den Thermostaten, über einen Standard mitteilen können.

Ich bin gespannt, ob Matter auch für so einen Fall gebaut ist oder ob der Schwerpunkt in Smart-Home-Zentralen größerer und kleinerer Hersteller liegt.

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.

Heute eine Nachricht in eigener Sache. Während immer mehr Nachrichtenportale sukzessive ihre RSS-Angebote einstellen, erlebt momentan ein Medium, das fundamental darauf aufbaut, einen kometenhaften Aufstieg in der Breite: der Podcast. Technisch handelt es sich dabei um eine Erweiterung des RSS-2.0-Standards und ermöglicht, dass der ein und selbe Inhalt an verschiedene Podcatcher, also Podcast-Clients, ausgespielt wird. Zunehmend übernehmen Streaming-Plattformen wie Spotify das Konzept und führen eigene Verzeichnisse hierfür ein.

Der Podcast ist in der Medienlandschaft längst angekommen und entwickelt sich zu einem beliebten Gesprächsformat. Es gibt bereits Stimmen, die ihn schon als Nachfolger des Blogs sehen. Besonders trenden Themen zu Politik, Wirtschaft, aber auch Technologie. Eine nicht zu unterschätzende Nische ist dabei die IT-Sicherheit – und diese Nische möchte ich in meinem neusten Projekt füllen.

Mein neuer Podcast „Risikozone“ geht ab morgen, dem 01. September 2022 an den Start und beschäftigt sich u. a. mit den Themen IT-Sicherheit, Open-Source-Software und Künstliche Intelligenz bzw. Maschinelles Lernen. Im Podcast kann ich endlich die Themen behandeln, die zu lang für einen Blogartikel, aber zu kurz für ein Video/-kurs sind, oder gar nicht in die beiden Kategorien passen. Es geht auch um Grundlagenthemen der Kryptographie, Computerkommunikation und des Datenschutzes sowie um aktuelle Nachrichten aus diesen Bereichen. Die Zielgruppe liegt in der Breite: es geht darum, IT zu vermitteln. Aus diesem Grund werden die technisch tiefgreifenden Themen weiterhin im Blog behandelt, während im Podcast weitere Themen Einzug finden können.

Pro Monat sollen mindestens zwei ca. 20 bis 45 Minuten lange Episoden enstehen, die dann über unterschiedlichste Wege abrufbar sind. In den Folgen werden entweder Gäste dabei sein oder ich werde alleine Schwerpunktthemen vorstellen.

Um den Podcast zu abonnieren, gibt es verschiedene Möglichkeiten: da heutzutage die Plattformökonomie auch bei Podcasts angekommen ist, möchte ich hier Spotify und Apple Podcasts erwähnen, bei weiteren Plattformen folgt die Listung in Kürze. Der Feed des Podcasts ist unter https://risikozone.de/feed/mp3/ erreichbar. Weitere Informationen und Aktualisierungen sind auch auf der entsprechenden Seite verfügbar.

Morgen Vormittag werden die beiden ersten Episoden veröffentlicht, in denen es um das Thema E-Mail-Sicherheit geht. Eine Trailerepisode 0 ist bereits jetzt schon verfügbar. Wie es dann weitergeht, könnt ihr mit eurem Feedback auch mitentscheiden. Gefällt es euch, habt ihr Themenvorschläge oder Anmerkungen? Das alles könnt ihr an info@risikozone.de schicken.

Darüber hinaus könnt ihr gerne, wenn euch der Podcast gefällt, euren Freunden und eurer Familie davon erzählen oder ihn auf Spotify und/oder Apple Podcasts bewerten und uns dort folgen.

Zur üblichen Arbeit eines Systemadministrators gehört der Umgang mit persistentem Speicher (a.k.a. Festplatte), der heutzutage in Form von HDDs, SSDs oder auch NVMes daherkommt. Üblicherweise werden in Produktivsystemen die Platten in einem RAID angeordnet, um bei einem Festplattenausfall die Verfügbarkeit des Systems zu erhöhen. Soll in diesem Zusammenhang allerdings eine Festplatte vor einem drohenden Ausfall manuell aus dem RAID entfernt werden, ist es ratsam, sie vorher sicher zu löschen. In diesem Artikel möchte ich allerdings kurz umschreiben, warum der Hinweis, Backups vor jeglicher Formatierung zu erstellen, so wichtig ist - besonders bei NVMe-Speichern.

Um die gleich folgende Syntax zu verstehen, sei noch gesagt, dass unter Linux ein bestimmtes Schema existiert, wie Festplatten oder eben NVMes angesprochen werden. Bei SCSI- bzw. SATA-Platten kennt man z. B. /dev/sda für die erste erkannte SATA-Festplatte (= sd für den Treiber und a für die Platte) und /dev/sda3 für die dritte Partition (= 3) auf der ersten erkannten SATA-Festplatte. Wichtig ist, dass "erste erkannte Festplatte" genau so relativ verstanden werden muss, wie es klingt. Wird, aus welchem Grund auch immer, eine andere Festplatte zu erst erkannt und ist die Buchstabenzuweisung nicht persistiert, ändert sich über mitunter auch die Zuweisung. Nicht ohne Grunde werden Linux-Nutzer angehalten, mit UUIDs eindeutig identifizierbare Bezeichner für ihre /etc/fstab zu nutzen.

Bei NVMe ist das scheinbar ähnlich, auch wenn es hier einen Zusatz gibt. Eine Partition auf einem NVMe-Gerät, das alleine in einem Rechner steckt (d. h. nur eine NVMe ist eingebaut) könnte /dev/nvme0n1p3 heißen. Hier bedeutet die Syntax, dass es sich um die dritte Partition (p3) auf dem ersten Namespace (n1) hinter dem Controller mit der Nummer 0, handelt, das über den NVMe-Treiber angesprochen wird. NVMes verfügen mit Namespaces über eine weitere Abstraktionsschicht, sodass der NVMe-Controller seinen Storage in Namespaces unterteilen kann, die jeweils über eine eigene Partitionstabelle verfügen.

Im administrativen Umgang arbeitet man oft mit mehreren Block-Devices, einerseits der "Platte selber", klassischerweise einer /dev/sda, und den Partitionen, also /dev/sda3. Bei NVMe ist die "Platte selber" in den allermeisten Fällen ein Namespace, also /dev/nvme0n1 und NICHT /dev/nvme0.

Es gibt allerdings ein Szenario, wo man mal den Controller direkt ansprechen muss: beim Kommando nvme format. Hier gibt es eine Syntax, wo als Argument das NVMe-Device, also der Controller, angesprochen und der Namespace per Option übergeben wird. Ich durfte nun erleben, wie das sehr, sehr schiefgehen kann.

Wer nämlich glaubt, dass man von /dev/nvme1n1 auf den Controller /dev/nvme1 schließen kann, irrt sich gewaltig. Diese beiden Bezeichner haben streng genommen nichts miteinander zu tun. Und so kann es dazu führen, dass wenn

• man zwei NVMe-Devices hat
• /dev/nvme1n1 behalten und
• /dev/nvme0n1 mittels nvme format /dev/nvme0 -n 1 löschen möchte,

man sich potenziell den Boden unter den Füßen wegzieht und die eigentlich zu behaltende NVMe löscht - was nach der Formatierung mit der netten Fehlermeldung bash: <executable>: cannot execute binary file: Exec format error quitiiert wird, wenn man das nächste Kommando in der Bash aufrufen will.

Der Zusammenhang wird zwischen /dev/nvmeX und /dev/nvmeYn1 nämlich - NVMe Multpathing sei dank - dynamisch gewählt. Und ich bin nicht der einzige, dem das aufgefallen ist. Normalerweise hängen die Bezeichner zusammen, aber wenn man beim Tausch der NVMes zwischendurch Reboots durchführen muss, kann sich die Reihenfolge schon mal verdrehen - aber eben nur halb.

Und so muss man manuell nachprüfen, welches Device wirklich hinter dem Block-Device eines Namespaces steckt:

me@server:~$ ls -l /sys/block/nvme1n1/device
lrwxrwxrwx 1 root root 0 Aug 31 19:43 /sys/block/nvme1n1/device -> ../../nvme0

In diesem Fall steckt hinter /dev/nvme1n1 das Device /dev/nvme0. Muss man beachten.

Dies hat übrigens nicht nur auf das Formatieren Auswirkungen: auch die SMART-Überwachung zeigt für /dev/nvme0n1 und /dev/nvme0 völlig unterschiedliche Resultate an. An dieser Stelle ist mir übrigens erst aufgefallen, dass der Zusammenhang zwischen den Devices mitunter nicht-systematisch gewählt werden könnte.

Was lernen wir daraus? Neue Treiber, wie in unserem Fall nvme, bringen neue Herausforderungen mit. Es ist gut, sich jedes Mal, wenn man seine Produktivsysteme mit neuen Fähigkeiten ausstattet, mit der Dokumentation und dem Standard hinter dem Treiber zu beschäftigen. Darüber hinaus - und das ist noch viel wichtiger - sollte man jederzeit auf seine Backups als zusätzliches Sicherheitsnetz achten, weil es immer etwas geben wird, was man übersieht. In meinem Fall hatte ich Glück, weil der betroffene Server aus der Testumgebung stammte und das Formatieren der falschen Platte nur vernachlässigbare Auswirkungen hätte - ich bin aber froh, auf diesem Umstand aufmerksam geworden zu sein und wollte euch an dieser Stelle einfach "vorwarnen".

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.

Im heutigen Artikel möchte ich euch kurz ein Werkzeug vorstellen, das immer dann sinnvoll ist, wenn mehrere Dateien auf einmal nach einem bestimmten Muster umbenannt werden sollen. Das Werkzeug heißt rename (man prename) und kann unter Debian/Ubuntu als solches aus den Repositories bezogen werden. Bei anderen Distributionen muss man darauf achten, dass man die Perl-Variante nimmt (teils auch als prename bekannt) und nicht auf die util-linux-Variante zurückgreift, die zwar simple Ersetzungen beherrscht, aber kein Regex/Perl-Expression beherrscht und nur den ersten Treffer im Dateinamen ersetzt.

Das Kommando ist relativ einfach aufgebaut:

rename OPTIONS perlexpr [ files ]

Die wichtigste Option, das möchte ich vorab schon sagen, ist -n, da hiermit ein "Trockenlauf" durchgeführt und somit überprüft werden kann, ob das Muster auch passt. Darüber hinaus halte ich -v für die zweitwichtigste Option, da man im "scharfen" Lauf dann überwachen kann, was konkret umbenannt wurde. Das Muster selber wird als Perl-Expression übergeben, die in vielen Fallen an die Syntax vom Kommandozeilenwerkzeug sed für die Ersetzung von Text erinnert.

Das Kommando kann dann zum Beispiel so eingesetzt werden:

rename 's/TEst/Test/g' *.txt

Hier sollen alle Stellen mit "TEst" in den Dateinamen, die auf .txt enden, durch "Test" ersetzt werden. Mit einem klassischen mv ließe sich das nicht ohne weiteres umsetzen, da dieses Werkzeug nicht kontextbezogen ersetzen/umbenennen kann.

Natürlich können auch komplexere (Regex)-Muster umgesetzt werden: soll z. B. die Dateiendung aller Dateien, die auf ".htm" enden, in ".html" umbenannt werden, geht das mit folgendem Kommando:

rename 's/\.htm$/\.html/' .htm

Weitere Beispiele und Bedienungshinweise können aus dem Ubuntuusers-Wiki bezogen werden. Meiner Erfahrung nach spart das Werkzeug besonders viel Zeit bei Umbennungsaufgaben und ersetzt somit ggfs. eigene Skripte mit find-mv-Konstruktionen.

Kryptographische Hashfunktionen sind ein wichtiger Grundpfeiler in der Kryptographie. Sie sind ein Spezialfall der normalen Hashfunktionen bzw. Streuwertfunktionen und ermöglichen die Erhaltung der Integrität von Informationen, insbesondere im Einsatz als Prüfsumme (engl. checksum). Die Kunst bei der Entwicklung einer kryptographischen Hashfunktion ist es, einerseits eine beliebig große Eingabemenge auf eine kleinere Zielmenge, bei der in der Regel die Elemente die gleiche Länge besitzen, abzubilden und andererseits darauf zu achten, dass es besonders schwer ist, zu einem beliebigen oder gegebenen Hashwert einen zweiten Eingabewert zu finden.

SHA-256 ist ein wichtiger Vertreter der modernen kryptographischen Hashfunktionen. Standardisiert wurde die Funktion u. a. in RFC 6234. Mein heutiger Webtipp sha256algorithm.com dreht sich um die Funktionsweise von SHA-256. Auf der Seite wird anschaulich dargelegt, wie eine Eingabe in die Ausgabe, den „Hash“ bzw. „Hashwert“ verwandelt wird. Dabei wird deutlich, dass die Funktionsweise mitunter deutlich komplexer erscheint, als angenommen – der Algorithmus aber trotzdem recht einfach ist und in knapp 160 Zeilen C-Code (hier ein Beispiel ohne Gewähr auf Standardkonformität) untergebracht werden kann.

Mir gefällt besonders die Interaktivität der Webseite. Eigene Eingaben können im ASCII/UTF-8-, Binär- oder Hexadezimalformat eingeben sowie verarbeitet und der Algorithmus Schritt für Schritt durchlaufen werden. Ebenfalls wird auf der Seite deutlich, dass die Zwischenwerte zum Erlangen des Hashwertes teilweise sehr durchmischt werden. Es lässt sich darüber hinaus erkennen, wie selbst eine „leere“ Eingabe so verarbeitet wird, dass ihre Ausgabe, der Hashwert, wenig Aufschluss über Wert und Beschaffenheit der zugrundeliegenden Eingabe bietet.

Wer genauere Details zu den verschiedenen SHA-Algorithmen sucht, kann im Anschluss im o. g. RFC-Dokument weiter fündig werden. Die Webseite hinter dem heutigen Webtipp wurde von Domingo Martin entwickelt, ihr Quelltext steht auf GitHub bereit.

Nahezu jeden Monat erscheint ein neuer Release von Firefox, bei dem die Hauptversionsnummer inkrementiert wird. Meist betreffen die Änderungen interne Komponenten oder das Design, manchmal ändern sie aber auch die Verhaltensweise.

Letzteres ist mir in Firefox 98 aufgefallen. Das Changelog berichtet von einer Änderung im Downloadverhalten:

Firefox has a new optimized download flow. Instead of prompting every time, files will download automatically. However, they can still be opened from the downloads panel with just one click.

Hintergrund

Offenbar soll das Verhalten dem Chrome angepasst werden. Downloads werden also sofort abgespeichert, eine Option für einen "temporären Download" in ein Verzeichnis, das nach Beendigung des Browsers auch bereinigt wird, entfällt vordergründig.

In meinen Augen ist dies aus zwei Gründen ein Rückschritt:

• Ich möchte bei einem Download vorher benachrichtigt werden, ob ich diesen weiterhin fortführen will. (Ja, ich weiß, intern lief der Download bereits, als dieser Dialog gezeigt wurde.)
• Nicht jede Datei möchte ich final abspeichern, viele PDFs sollen lediglich nur in der Sitzung angezeigt werden. Die Integration von pdf.js war hier sehr charmant gelöst.

Besonders bei PDFs fällt mir das neue Verhalten negativ auf, da man nicht im Vorhinein sehen kann, ob ein Content-Disposition-Header mitgesendet wird. Mit diesem HTTP-Header kann nämlich serverseitig empfohlen werden, ob ein Inhalt wie z. B. ein Bild oder PDF lediglich dargestellt oder zum Download angeboten werden soll.

Altes Verhalten wiederherstellen

Leider hat sich Mozilla dazu entschieden, nicht dem klassischem Nutzer zu überlassen, wie Downloads stattfinden sollen, da eine Einstellungsoption für die Verhaltensweise (d. h. ob neu oder alt) fehlt. Glücklicherweise gibt es für versierte Anwender mittels about:config trotzdem (noch) die Möglichkeit, das alte Verhalten wiederherzustellen. Maßgeblich hierfür ist der Schlüssel browser.download.improvements_to_download_panel, dessen Wert standardmäßig true ist. Ändert man diesen in false, wird der Downloaddialog wieder angezeigt. Unabhängig von der Namenswahl, die leider viele Änderungen unter dem Begriff "improvements" zusammenfasst, muss man selbstverständlich wissen, dass diese Änderung (und somit das alte Verhalten) nicht mehr unterstützt ist und somit zukünftig auch entfernt werden könnte.

Einschätzung

Momentan lässt sich am Firefox der Trend beobachten, dass sich in vielen Funktionalitäten am Chrome/Chromium-Browser orientiert wird. Leider kommen dabei viele Besonderheiten unter die Räder, die die Personalisierbarkeit des Browsers erst ausgemacht haben. Zwar kann man grundsätzlich das permanente Downloadziel weiterhin einstellen, eine weitere Einstellungsmöglichkeit für temporäre Downloads würde einigen Anwendern aber entgegenkommen. Glücklicherweise lässt sich das Verhalten auch weiterhin intern einstellen, es ist aber fraglich, ob diese Option langfristig erhalten bleibt.

Weiterführende Links

• Mozilla Support Forum: Firefox now saves files that I only wanted to open, 10.03.2022

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!

Kurz angemerkt: beim Update eines GitLab-Servers per APT trat folgende Fehlermeldung auf:

The following signatures were invalid: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com>

Der Hintergrund ist recht einfach und wird auch auf der entsprechenden Hilfeseite erklärt:

This key’s expiration was extended from 2022-03-02 to 2024-03-01. If you encounter a complaint of expiration on 2022-03-02, perform the steps in Update keys after expiry extension to incorporate the updated public key content.

So lief tatsächlich der Repository Key in der Mitte der Woche regulär aus und muss nun erneuert bzw. aktualisiert werden, da seine Laufzeit erweitert wurde. Die Anleitung, wie man den Key aktualisieren kann, wird auf besagter Hilfeseite ebenfalls zur Verfügung gestellt. Danach verläuft das Upgrade wieder wie gehabt.

[GitLab.com Issue]

Kurz notiert: Rust ist in Version 1.59 erschienen. Die spannendste Neuerung ist hierbei aus meiner Sicht die Unterstützung für Inline-Assembly-Instructions. Dabei lassen sich innerhalb von Rust-Quellcodedateien Assembly-Instructions übergeben, die so in das Kompilat übernommen werden können. Dies ist immer dann nötig, wenn bestimmte Spezialbefehle benötigt werden, welche der Compiler nicht standardmäßig ausgibt.

Manuelle Assembler-Programmierung wird bei den meisten Programmen nicht benötigt. Beispiele sind eher vor allem in der Embedded-Programmierung zu finden, wo meist direkt Interrupts konfiguriert werden, die wiederum in vielen Architekturen über spezielle Operationen eingestellt werden können. Aber auch der Einsatz von SIMD benötigt spezielle Befehle. Dies ist besonders für Bibliotheken hilfreich, die Daten parallel verarbeiten.

Klassischerweise können die Assembler-Module in .S-Dateien geschrieben werden, welche dann, ähnlich wie C-Dateien, zu .o-Objektdateien assembliert resp. übersetzt werden. Verschiedene Objektdateien, welche auch aus unterschiedlichen Programmiersprachen stammen können, lassen sich dann zu einem Programm linken. Die Option von Assembler-Sektionen innerhalb einer höheren Programmiersprache vereinfacht den Umgang allerdings deutlich. So bietet auch GNU GCC für C ein spezielles asm-Keyword an, mit dem direkt Assembler-Befehle übergeben werden können. Mehr Informationen diesbezüglich bietet die GCC-Doku.

Das Rust By Example-Handbuch bietet eine eigenen neue Sektion zur Inline Assembly mit Beispielen an. Es lässt sich erkennen, dass es einige Parallelen zum C-Äquivalent gibt, obgleich die Syntax Unterschiede aufweist. Es ist möglich, ähnlich wie bei format-Strings, Zusatzinformationen zu Variablen und Registern zu übergeben. Dabei sollte jedoch bedacht werden, dass für den asm-Code natürlich keine strenge Typsicherheit gelten kann und der Einsatz nur innerhalb von unsafe-Blöcken möglich ist.

Weitere Änderungen in der neuen Rust-Version beziehen sich auf destructuring assignments und const generics-Standards und Verschachtelungen. Die destructuring assignments können bei der Lesbarkeit helfen, da mehrere Werte auf der rechten Seite mehreren Variablen auf der linken Seite in einem Statement zugewiesen werden können. Ähnliches ist man auch schon im Python mit dem Unpacking gewohnt.

Alles in allem aus meiner Sicht ein sehr spannender Release, der besonders die Entwickler von Bibliotheken freuen wird, da weitere Optimierungsmöglichkeiten komfortabler zur Verfügung stehen.

Zum Ende des Monats möchte ich euch diesen Webtipp nicht vorenthalten. Es gibt viele Webseiten, die Dinge gut und anschaulich erklären. Mitte des Monats bin ich jedoch auf einen Artikel gestoßen, der das richtig gut umsetzt: GPS von Bartosz Ciechanowski. Er hat eine interaktive Webseite gebaut, auf der die Funktionalität vom Global Positioning System (Wikipedia) erklärt wird. Von der Funktionsweise ist sie zwischen einer Physiksimulation und einem Spiel einzuordnen. Verständlich, anschaulich und „clean“ – das findet man heutzutage selten. Technisch ist das Ganze dabei offenbar in WebGL geschrieben.

Wer schon immer mal wissen wollte, wie Satellitennavigation funktioniert, findet auf der Webseite eine wunderschöne Erläuterung. Sicherlich einen Besuch wert.