🔒
Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeVNotes

Jahreswechsel 2022/2023

31. Dezember 2022 um 23:50

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!

Fallstricke beim Einsatz von NTP und verschlüsseltem DNS

30. Dezember 2022 um 21:45

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 durchsuchen

30. November 2022 um 22:08

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.

Sicherheitslücken im WLAN-Stack des Linux-Kernels

16. Oktober 2022 um 17:00

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.

Smart-Home-Standard Matter 1.0 erschienen

05. Oktober 2022 um 13:28

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.

(Wikipedia contributors. Matter (standard). Wikipedia, The Free Encyclopedia. October 5, 2022, 05:54 UTC. Available at: https://en.wikipedia.org/w/index.php?title=Matter_(standard)&oldid=1114175110. Accessed October 5, 2022.)

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.

Matter CHIP IP Pyramid

Abbildung 1: Protokollpyramide, Quelle: GitHub project-chip/connectedhomeip, Autor: Project CHIP Authors, Lizenz: Apache 2.0

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.

Rust in Linux 6.1 erwartet

30. September 2022 um 23:32

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.

Neuer Podcast über IT-Sicherheit: Risikozone

31. August 2022 um 22:20

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.

Falscher NVMe-Speicher formatiert? Devicenamen beachten!

31. August 2022 um 21:00

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

OPNsense 22.7 erschienen

30. Juli 2022 um 21:47

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.

Vim 9 erschienen

30. Juni 2022 um 23:00

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.

rename: mehrere Dateien nach einem Muster umbenennen

31. Mai 2022 um 21:15

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.

SHA-256 visualisiert

30. April 2022 um 21:52

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.

Downloaddialog in Firefox 98 wieder anzeigen

20. März 2022 um 20:00

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

Arch Linux wird 20 Jahre alt

11. März 2022 um 23:45

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!

Debian/Ubuntu-Repositories von GitLab haben neuen Key

06. März 2022 um 17:05

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]

Rust 1.59 erschienen

28. Februar 2022 um 21:00

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.

Wie funktioniert eigentlich... GPS?

31. Januar 2022 um 23:05

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.

Jahresrückblick 2021 und Ausblick

31. Dezember 2021 um 23:30

In wenigen Minuten endet 2021. Wagen wir deshalb einen kurzen Blick zurück und schauen, was uns erwartet.

Dieses Jahr habe ich im Blog 20 Artikel verfasst, bei denen ich überwiegend dem Open-Source-Schwerpunkt treu geblieben bin. Es gibt darüber hinaus eine komplett neue Kategorie „Wirtschaft“, die ich erstmals im Mai diesen Jahres ausprobiert habe. Hier soll es mehr um aktuelle Entwicklungen in der Wirtschaft, speziell bei Kryptowährungen und Smart Contracts, gehen. Bitcoin, Ethereum & Co. haben sowieso dieses Jahr dominiert und mehrfach neue Höchststände erreicht. Auch hier schreitet die Entwicklung schnell voran und wird uns in den nächsten Jahren begleiten.

Hier schließt nahtlos das Jahr 2022 an. Ich möchte diesen Blog kontinuierlich fortführen und weiterentwickeln. Selbstverständlich könnt ihr auch im kommenden Jahr spannende Artikel erwarten. Der Microblog wurde bereits in diesem Jahr tiefer in den Blog integriert, sodass die kürzeren Beiträge einfacher erreichbar werden. So sich die Gelegenheit bietet, wird der Microblog auch stärker ausgebaut.

Ich wünsche euch jedenfalls jetzt einen guten Rutsch und vor allem viel Gesundheit und Freude im Jahr 2022!

Bash-Kommandos erklären lassen

31. Dezember 2021 um 18:08

Wer Linux intensiv nutzt, wird um die Kommandozeile nicht herumkommen. Hier läuft meist eine Shell, die kompatibel zur Bash ist oder bei der es sich direkt um die Bash handelt.

Interessant bei Bash (und vielen anderen Shells) ist die Leistungsfähigkeit. So beschränkt sich die Kommandozeile nicht auf einfache Programmaufrufe, sondern bietet einige Ausdrücke, die in Verbindung mit kleinen Hilfsprogrammen unter anderem bedingte Anweisungen oder Schleifen ermöglichen. Leider ist die Syntax im Gegensatz zu anderen Skriptsprachen manchmal ungewohnt, weswegen unregelmäßige Anwender öfter mal in der Dokumentation nachlesen müssen.

Eine interessante Unterstützung bietet hierbei explainshell.com. Hier kann man einen Bash-Ausdruck eingeben und ihn sich von der Seite erklären lassen. Dabei werden nicht nur die Manpages der verwendeten Kommandos wie find, grep oder git, sondern auch die passenden Auszüge der bash-Manpage selber eingebunden. Dies wird zusätzlich anschaulich visualisiert.

Der Quellcode von explainshell.com ist GPL-3-lizenziert und auf GitHub verfügbar.

ssh-rsa bei OpenSSH 8.8 explizit aktivieren

30. November 2021 um 10:14

Im Februar 2020 wurde schon angekündigt, dass OpenSSH die Unterstützung von ssh-rsa auslaufen lässt. Umgesetzt wurde dies in Version 8.8, die vor gut einem Monat veröffentlicht wurde.

Leider unterstützt nicht jedes System moderne HostKeyAlgorithms. Ein solches Beispiel konnte ich die Tage z. B. bei einem Switch beobachten konnte. Hier erscheint folgender Fehler:

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

In so einem Fall kann man ausnahmsweise doch noch ssh-rsa erlauben und das geht entweder per Option im ssh-Aufruf:

ssh -o HostKeyAlgorithms=+ssh-rsa 192.168.1.1

oder man trägt es in die ~/.ssh/config dauerhaft ein:

Host XYZ
    HostName 192.168.1.1
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

realpath zeigt absolute Pfade an

31. Oktober 2021 um 18:42

Kurz notiert: es gibt Situationen, in denen man Pfade auflösen, also relative Pfade in absolute umwandeln möchte. Für Anwender, die dabei Konstruktionen mit pwd und kompliziertes Parsing umgehen wollen, bietet sich realpath aus den GNU Coreutils an.

Die Bedienung ist denkbar einfach: realpath nimmt beliebig viele Pfade als Argumente auf und gibt die absoluten Pfade zeilenweise aus. Dabei werden standardmäßig auch Symlinks aufgelöst, sodass der „wahre“ Pfad, im Programmkontext auch physischer Pfad genannt, angezeigt wird.

Mit einigen Zusatzoptionen, die sich in der Manpage realpath(1) finden lassen, kann weiterhin das Verhalten angepasst werden. Hier sei zum Beispiel -e erwähnt, das einen strikteren Modus aktiviert und überprüft, ob das letzte Element im Pfad überhaupt existiert – stanardmäßig ist dies nicht der Fall. Mit -s kann die bereits beschriebene Auflösung von Symlinks deaktiviert werden.

Alles in allem, ein hilfreiches Werkzeug, besonders für Shellscripte. Der Quelltext von realpath ist auch überschaubar und beispielsweise auf GitHub zu finden.

OpenSSL 3.0 erschienen

07. September 2021 um 16:21

OpenSSL ist eine Softwarebibliothek, die Implementierungen für bestimmte kryptographische Verfahren, die besonders in der Netzwerkkommunikation eingesetzt werden, bereitstellt. Heute wurde Version 3.0 veröffentlicht.

Neue Versionierung

Anwender und Entwickler, die bereits mit OpenSSL arbeiten, werden mitunter erschrocken sich fragen, warum dieser Versionssprung stattfindet – so war zuletzt Version 1.1.1l aktuell und OpenSSL für eine sehr zurückhaltende Numerierung bekannt.

OpenSSL steigt nun allerdings, wie bereits 2018 angekündigt, auf die Semantische Versionierung um, welche ein klares Schema vorgibt, welche Änderungen zu welcher Anhebung der Versionsnummer führen. Dabei liegt der Dreh- und Angelpunkt bei der API: wird die erste Versionsnummer (Major) erhöht, gibt es Änderungen an der API, die nicht abwärtskompatibel sind. Ergänzungen erhöhen die Versionnummer hinter dem ersten Punkt und Patches die nach dem zweiten Punkt. Ein Sprung von 1.1.1 auf 3.0 steht also für nicht abwärtskompatible API-Änderungen, weswegen alle, die auf OpenSSL setzen, einen Blick auf die Neuerungen werfen sollten, die wir uns gleich anschauen werden. Die Versionnummer 2.0 wurde im Übrigen übersprungen, da teilweise das FIPS-Modul schon auf die Weise numeriert wurde.

Änderungen

Folgende Änderungen fallen im Changelog auf:

  • Mit Version 3.0 wird ein neues Konzept zur Modularisierung eingeführt: die Provider. Sie ersetzen die ENGINE API sowie dessen Implementierungen und sollen die Wartbarkeit der Implementierungen erhöhen. Algorithmen können nun flexibel eingeführt werden, solange es eine API gibt, die den entsprechenden Typen unterstützt. Das Kontext wird in der entsprechenden Man-Page ausführlich erklärt. Die Algorithm Types heißen nun Operationen (operations).

  • Weiterhin soll vor allem aufgeräumt werden. Dafür wurden viele API-Funktionen als veraltet deklariert, darunter TLS_MAX_VERSION, DTLS_MAX_VERSION, DTLS_MIN_VERSION und viele Low-Level-Funktionen.

  • Ein Byte-Order-Mark am Anfang von PEM-formatierten Dateien wird nun ignoriert.

  • Die Validierung der Operationsparameter kann nun solange verzögert werden, bis die eigentliche Operation stattfindet, da die Implementierungen der kryptographischen Operationen in die Provider verschoben wurde. Somit lässt sich das Verhalten und die Fehlerbehandlung verändern. Als Beispiel wird angeführt, dass der Funktionsaufruf einer nicht unterstützen Kurve mit EVP_PKEY_CTX_set_ec_paramgen_curve_nid() nicht fehlschlagen wird, wohl aber Funktionen zur Schlüsselgenerierung mit EVP_PKEY_CTX.

  • ERR_GET_FUNC() wurde vollständig entfernt.

  • Datumsangaben können nun gemäß ISO 8601 formatiert werden. Dies ist allerdings keine Standardeinstellung.

  • Weiterhin gibt es Änderungen bei den Funktionssignaturen. So wechseln die Signaturen der Funktionen zum Setzen oder Ausgebnen von Optionen für SSL und SSL_CTX von unsigned long auf uint64_t. Somit kann sichergestellt werden, dass die Datentypen auf allen Systemen exakt 64 Bit lang sind statt der bisherigen Anforderung auf mindestens 32 Bit. Nebenbei entspricht ein uint64_t einem long long.

  • Clientseitig initiierte Renegotiations sind nun standardmäßig deaktiviert und können mit z. B. -client_renegotiation oder SSL_OP_ALLOW_CLIENT_RENEGOTIATION wieder aktiviert werden.

  • abspath- und includedir-Pragmas werden im Code verwendet, um Sicherheitsrisiken durch relative Inkludierung aus dem Weg zu gehen.

  • Die APIs für PKCS#12-Dateien, die oft eingesetzt werden, um Private Key und Zertifikat in einer Datei zu speichern, wurden so erweitert, dass sie nun einen Bibliothekskontext akzeptieren. pkcs12 selber nutzt nun PBKDF2, AES und SHA-256 mit einem MAC-Iterationszähler gemäß PKCS12_DEFAULT_ITER. openssl pkcs12 gibt überdies nun alle PKCS#12-Attribute und nicht mehr nur das erste aus.

  • Linux' Kernel TLS wird nun unterstützt.

  • Ausgaben verschiedener Kommandos wurden leicht angepasst.

  • openssl speed greift nun nicht mehr auf Low-Level-APIs zurück.

  • Die verfügbaren Provider können nun per openssl list -providers angezeigt werden.

  • CMP und CRMF gemäß RFC 4210, 4211 und 6712 wurden hinzugefügt.

  • DH Modulos müssen nun mindestens 512 Bits lang sein.

  • FFDHE Key Exchange in TLS 1.3 wird nun unterstützt.

Der Fokus lag bei diesem Release besonders beim FIPS-Modul. Darüber hinaus strebt OpenSSL eine Zertifizierung nach FIPS 140-2 an, weswegen einige Änderungen Anpassungen an Standards enthalten. So wird z. B. nicht mehr möglich sein, mehr als 264 TLS Records in einem Zug mit AES-GCM zu verschlüsseln, um die Einzigartigkeit von Schlüssel und Intialisierungsvektor (IV) zu gewährleisten. PBKDF2 orientiert sich überdies nun an SP800-132 statt an PKCS#5 RFC 2898.

Diese zahlreichen Änderungen machen mitunter eine Migrationen bei allen OpenSSL-einsetzenden Programmen notwendig. Die OpenSSL-Entwickler stellen hierfür eine entsprechende Migrationsanleitung bereit.

Neue Lizenz

Zu guter Letzt gibt es Anpassungen bei der Lizenz. OpenSSL 3.0 steht unter der Apache License 2.0. Somit gilt nun nicht mehr die angepasste BSD-Lizenz, die eine Werbeklausel enthält. Die Umstellung wurde bereits vor vier Jahren anvisiert.

Kurzeinordnung

Es freut mich, dass sich einiges beim OpenSSL-Projekt tut. Die Liste der Änderungen ist lang, es wird viel bereinigt. Allerdings bleibt in meinen Augen die Sorge, dass dieser große Release langsamer als sonst seinen Weg in die Endprodukte findet. OpenSSL wird in allen möglichen Systemen auch fernab von klassischen Computersystemen eingesetzt und stellt somit das Rückgrat sicherer Netzwerkkommunikation dar. Die Umstellung der Versionierung sorgt nicht nur für kurze Verwirrung, sondern sollte auch im Hinterkopf behalten werden, wenn Versionsprüfungen fehlschlagen: sie könnten so programmiert sein, dass sie nur den Major-Release überprüfen - dabei sollte der überwiegende Teil der Software, die bereits mit 1.1.1l lief, auch mit OpenSSL 3.0 laufen.

Linux wird 30 Jahre alt

25. August 2021 um 23:20

Genau auf den Tag vor 30 Jahren erreichte in diesen Minuten die Welt eine Nachricht, die sie nachhaltig gestaltete: Linus Torvalds hat in der Usenet-Gruppe comp.os.minix seine Arbeit an einem Betriebssystem angekündigt, das später als Linux bekannt werden und große Teile der Computerindustrie, vor allem das Internet, dominieren sollte. Der Rest ist Geschichte.

Ich bin zwar erst seit 2010 dabei, aber doch überrascht, dass ein solches System wie Linux niemals einen „fertigen“ Status erreichen wird. Klar, neue Geräte und neue Treiber braucht es immer, aber selbst Kernkomponenten befinden sich in einem ständigen Wandel. Beispiel: Paketfilter. Während sich iptables gewissermaßen etabliert hat, gilt es schon längst als veraltet: nftables soll hier für die Ablösung sorgen. Aber auch hier steht mit eBPF ein weiterer potentieller Nachfolger bereits in den Startlöchern. All dies hat natürlich auch mit den stetig wechselnden Anforderungen zu tun, aber auch hier zeigt sich mit der Anpassungsfähigkeit der Vorteil von Open Source. Programmierer können stetig eigenmächtig neue Module entwickeln, die dann in den Hauptzweig aufgenommen werden können.

Und die größten Änderungen stehen erst noch an: so bereitet das Projekt Rust for Linux eine zweite Programmiersprache neben C für die Treiberentwicklung vor. Es bleibt also spannend.

Happy Birthday, Linux!

Uniswap erscheint auf Optimistic Ethereum in Alpha-Version

15. Juli 2021 um 17:16

Kurz notiert: Uniswap, die Kryptowährungsbörse, die sich komplett in einem Smart Contract abbildet und Anfang des Jahres ihre dritte Generation veröffentlicht hat, kündigt nun an, mit Optimistic Etheruem ein erstes Layer-2-System testweise zu unterstützen. Dabei handelt es sich um einen Alpha-Release, der höchstens für Tests geeignet ist, da das Risko des vollständigen Verlustes eingezahlter Werte noch hoch ist.

Vorteile sollen geringere Transaktionsgebühren und eine höhere Geschwindigkeit sein. Um Optimistic zu nutzen, transferiert man den gewünschten Beitrag zum Optimstic Gateway-Contract, der eine Art Portal dargestellt. Dann stellt dann seine Ethereum-Clients auf Optimistic um und kann Uniswap über Optimistic Ethereum nutzen.

Momentan sind noch diverse Einschränkungen vorhanden, da es sich um eine Demo handelt, die das theoretische Potential in einem Feldversuch demonstrieren soll. Rücktransfers auf Ethereum sind mit einer Sperrfrist von 7 Tagen belastet, es gibt nur fünf handelbare Token, Störungen sind nicht zu vermeiden und der Transaktionsdurchsatz ist bewusst auf 0,6 Transaktionen pro Sekunde beschränkt.

❌