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

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.

Unix-Timestamp im Terminal anzeigen

30. Juni 2021 um 22:40

Kurzer Tipp: in der Linux-Welt ist häufig, wenn es um Zeitangaben geht, die sog. Unixzeit anzutreffen. Hierbei werden die Sekunden nach dem 01.01.1970 00:00 Uhr UTC angegeben. So kann einfach eine Datumsangabe abgespeichert werden und anschließend mit den richtigen Methoden wieder umgerechnet werden. Möchte man den aktuellen Zeitstempel im Terminal anzeigen, kann man folgenden Aufruf nutzen:

date +%s

Nicht intuitiv zu finden, aber doch effektiv. So muss man nicht den Umweg über Webseiten oder eigens dafür entwickelte Programme gehen.

Linux 5.12.13 und Probleme mit AMD GPU

26. Juni 2021 um 12:20

Kurz notiert: wer eine AMD GPU mit VEGA-Technologie nutzt, wird wenig Freude mit Linux 5.12.13 haben. Nach dem Kernelupdate fiel mir auf, dass der GPU-Lüfter durchgängig lief und sensors einen durchgängig hohen Stromverbrauch, auch bei abgeschaltetem Display Manager, angab. Komischerweise war der Google-Vorschlag bei "linux 5.12.13" auch sofort "gpu usage". Ein kurzer Blick ins 5.12.13 shortlog zeigt, dass es tatsächlich Änderungen an den amdgpu-Treibern gab.

Hier ist der dazugehörige Bug im Bugtracker des Kernelteams und hier der Revert im Code.

Der Autor Yifan Zhang von AMD gibt als Grund an:

Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases.

Der Fix sollte somit in den nächsten Versionen inkludiert sein.

Ether durchbricht erstmals die 4.000 US-Dollar-Marke

10. Mai 2021 um 15:06

Für die zweitgrößte Kryptowährung Ether, die zum Ökosystem von Ethereum gehört, läuft es momentan richtig gut: ihr Preis durchbrach heute morgen um ca. 05:00 Uhr deutscher Zeit die 4.000 US-Dollar-Marke (umgerechnet 3.280 Euro) und erreicht somit das Allzeithoch.

Im Gegensatz zu Bitcoin ist Ethereum breiter aufgestellt und stellt mehr Möglichkeiten zur Anwendung in den Vordergrund: so ist dieses verteilte System für die Smart Contracts bekannt und wird auch gerne als „World Computer“ bezeichnet, da die Transaktionen auf allen Nodes aller Teilnehmer gemeinschaftlich verarbeitet werden. Bitcoin verfügt zwar auch über eine Scriptsprache, diese ist allerdings nicht Turing-vollständig. Die Ethereum VM, die über diese Eigenschaft verfügt, kann somit im theoretischen Sinne jedes berechenbare Problem lösen – wie die meisten üblichen Programmiersprachen. Auf der Etherum-Blockchain können somit klassische Computerprogramme laufen – sofern sie entsprechend portiert wurden.

Ether steht seit einigen Wochen mit Allzeithochs in den Schlagzeilen: so stieg die Kryptowährung vor 3 Monaten auf über 2.000 US-Dollar und passierte vor einer Woche die 3.000 USD-Marke.

Weitere aktuelle Daten liefert CoinMarketCap: momentan verfügt Ether über eine Marktkapitalisierung von 475 Milliarden US-Dollar. Das Handelsvolumen der letzten 24 Stunden bemisst sich gemäß der Quelle auf über 52 Milliarden US-Dollar. Während der Rivale Bitcoin die doppelte Marktkapitalisierung aufweist, verhält sich das Volumen in den letzten 24 Stunde ähnlich (zum Vergleich: BTC Volumen 60 Mrd. US-Dollar).

Wichtig in dem Zusammenhang ist auch der strukturelle Aufbau der Währung: Ether verfügt bisher über keine fixe, maximale Geldmenge, während Bitcoin bei etwa 21 Millionen BTC gedeckelt ist. Ein solches oberes Limit ist allerdings nicht zuletzt wegen Ethereum 2.0 im Gespräch, um bestimmten Effekten, darunter Inflation, entgegenzuwirken. Die Diskussion des am 01. April 2018 von Ethereum-Gründer Vitalik Buterin eingebrachten Vorschlags wird momentan im Rahmen des EIP-960 diskutiert. Als EIP (Ethereum Improvement Proposals) werden gemeinschaftliche Vorschläge bezeichnet, die die Verfahrensweise des Ethereum-Systems ändern können und als Maßgabe für alle Teilnehmer am System gelten. (ähnlich wie eine ISO-Norm oder eine Internet-RFC)

Die hohen Preise haben allerdings nicht nur Vorteile: da die Gebühren für Transaktionen weiterhin in Ether berechnet werden, werden Transaktionen auf Ethereum-Blockchain in US-Dollar oder Euro gemessen immer teurer. Abhilfe soll hier der EIP-1559 bringen: hiermit soll das Gebührensystem neu strukturiert werden, um die Gebühren faktisch zu senken. Dies ist vorteilhaft für die Nutzer und nachteilhaft für die Miner.

Ethereum stehen verschiedene Schlüsselereignisse bevor: so gehören Miner mit Ethereum 2.0 mehr und mehr der Geschichte an, da der Konsensalgorithmus von Proof of Work auf Proof of Stake umgestellt wird. Die Umstellung wird in diesem Jahr weiter vorangetrieben.

Auch außerhalb der Kryptowährungswelt richten sich die Augen mittlerweile auf Ethereum: so hat die Europäische Investitionsbank (EIB) vor knapp zwei Wochen bekannt gegeben, einen 120 Millionen US-Dollar-Bond aufzusetzen.

Kommentar

Die durchbrochenen Preismarken sind in meinen Augen besonders psychologisch wichtig und steigern die Akzeptanz des gesamten Systems. Es wird spannend zu sehen sein, wie sich Ethereum in den nächsten Monaten entwickelt. Besonders der Fakt mit den möglichen Anwendungen durch die Smart Contracts werden meiner Meinung ausschlaggebend für die Entwicklung sein.

Ich werde die nächste Zeit weiter in meinem Blog die technischen Entwicklungen erläutern und euch auf dem aktuellen Stand halten!

Weitere Informationen

Regulatorischer Hinweis / Haftungsausschluss

Dieser Artikel beschäftigt sich mit technischen Aspekten von Ethereum. Dieses Informationsangebot ist keine Anlageberatung. Die hier gegebenen persönlichen Einschätzungen stellen **keine Handlungsempfehlung**, keine Handlungsaufforderung und keinen Ersatz für eigene Recherche oder professionelle Beratung dar. Kryptowährungen sind hochriskant und können mindestens zum Totalverlust des Einsatzes führen.

Audacity, eine Übernahme und Telemetriefunktionen

08. Mai 2021 um 20:07

Audacity soll nach der Übernahme durch die Muse Group Telemetriefunktionen erhalten. Ein Kommentar über den Sinn und Unsinn solcher Funktionen, Diskussionen und Übernahmen von Open Source-Projekten.

Vor einigen Tagen ging die Meldung durch den Ticker, dass die Audiobearbeitungssoftware Audacity (Link zu audacityteam.org) durch Muse Group gekauft wurde. (LinuxNews und heise.de berichteten). Ich war über diese Meldung etwas überrascht, weil es etwas seltsam ist, ein OSS-Projekt zu „kaufen“. Die Software an sich ist GPLv2-lizenziert und ansonsten lässt sich lediglich eine US-Wortmarke finden. Ich konnte nicht einmal eine deutsche/europäische Marke hierzu ausfindig machen. Es geht bei dem Vorhaben der Muse Group sicherlich eher darum, den Einfluss auf die Entwicklung von Audacity auszubauen, um das eigene Produktportfolio zu erweitern.

Tantacrul hat diesbezüglich ein 15-minütiges Video zu seinen neuen Aufgaben erstellt, das auf YouTube verfügbar ist.

Es ist sehr zu begrüßen, dass ein Unternehmen die Mittel bereitstellt, eine Software wie Audacity weiterzuentwickeln. Ein Vorteil von kommerziell getriebener Entwicklung ist es, dass Leute dafür bezahlt werden, die unschöne, aber nötige Arbeit zu erledigen, um die Qualität beim Gesamtprodukt zu steigern. Auf der anderen Seite tauchen natürlich bei einer solchen „Übernahme“, die sich bei so einem Projekt immer noch ungewohnt anhört, Befürchtungen auf, dass Interessenkonflikte zu einer Strategieänderung bei der Entwicklung führen. Darüber hinaus ändert sich mitunter die Kultur der Entwicklung und die Gemeinschaft wird mit neuen Vorstellungen konfrontiert.

Dass es irgendwann Krach gibt, habe ich nicht ausgeschlossen. Dass es aber so schnell geht, hätte ich auch nicht gedacht. Am Dienstag, dem 04. Mai wurde ein Pull Request eröffnet, der den Namen „Basic telemetry for the Audacity“ trägt. Zum Zeitpunkt, an dem ich diesen Artikel hier schreibe, umfasst der Diskussionsthread schon über 850 Beiträge und wurde als „Draft“ zurückgestuft. Bei diesem offenbar kontrovers diskutierten Thema geht es darum, Audacity Telemetriefunktionen zu verpassen.

Ich könnte jetzt mit euch die konkreten Änderungen Stück für Stück auseinander nehmen, aber die dort verknüpften GitHub-Kommentare (besonders die Emojis) sprechen für sich. Alle, die einen C++-Hintergrund haben und CMake kennen, können sich die Implementierung zu Gemüte führen. Ich werde an geeigneter Stelle vereinzelt darauf eingehen.

Ein Glaubenskrieg

Telemetrie ist immer ein heikles Thema, besonders in der Open-Source-Welt. Hierbei geht es darum, die Nutzungsweise der Software an eine zentrale Stelle, dem Hersteller, zu melden, damit dieser Schlüsse daraus ziehen kann. Geht man noch einen Schritt weiter zurück, geht es darum, die Nutzung der Software messbar zu machen. Dies ist besonders im Management beliebt, da es Außenstehenden die Möglichkeit gibt, die Nutzung der Software zu analysieren und die Entwicklung zu regeln. Fragen wie „Entwickle ich an der richtigen Stelle?“, „Wollen die Nutzer das?“ oder „Haben wir genug Nutzer?“ sollen damit beantwortet werden.

In der vollen Ausbaustufe gleicht die Telemetrie einer Bildschirmaufnahme, bei der jeder Klick, jede Eingabe und jede Ausgabe an den Hersteller versendet werden. Das alles ist bei dem oben genannten Pull Request nicht der Fall, wie das Team nachdrücklich beteuert. Datenschutzrechtliche Aspekte lasse ich in dieser Betrachtung erst einmal außen vor, weil diese Diskussion das eigentliche Problem verschleiert.

Das Problem an diesem gesamten Umstand mit der Telemetrie ist, dass FOSS, also freie, offene Software, vom „mündigen Anwender“ ausgeht. Ich habe dieses Thema schon mal im Blog thematisiert. Dabei wird eine sehr aufgeklärte Weltanschauung vertreten: hat ein Anwender ein Problem, meldet er sich in einem Issue Tracker oder der Mailing Liste. Nur hat dieses Wunschdenken nichts mehr mit der Realität zu tun, vor allem, wenn die Zielgruppe nicht größtenteils aus Softwareentwicklern besteht, die diese Verfahrenswege kennen. Jetzt gibt es zwei Möglichkeiten: entweder auf das Feedback verzichten oder andere Wege finden, die Metriken zu erheben. Die Metriken sind zudem nur dann aussagekräftig, wenn sie eine repräsentative Nutzermenge abbilden - ergo: man müsste sie bei allen erzwingen.

Erschwerend kommt bei Audacity dazu, dass wir es hier mit einer Offline-Anwendung zu tun haben. Ist man es bei Webseiten gewohnt, dass die Inanspruchnahme von solchen zwangsläufig Verkehrsdaten erzeugt (seien es die Browserhistory, Logfiles auf dem Server, Analytics, o. ä.), so erwartet man bei lokaler Software nicht, dass diese „nach Hause telefoniert“. Zumindest früher.

Genau das soll bei Audacity jetzt allerdings passieren. Hierzu wurde extra die cURL-Bibliothek in den Source Tree eingefügt, was nebenbei noch eine komplett neue Abhängigkeit mit sich bringt. Diese Abhängigkeit wurde sogar sehr brachial hinzugefügt, wie aus dem diff hervorgeht, da während des Bauens sich Inhalte aus dem Git-Repository heruntergeladen werden sollen.

Die Telemetriedaten werden an ein zentrales Konto bei Google Analytics und Yandex geschickt.

FOSS-Prinzipein

Hier ergibt sich teilweise ein Bruch mit den üblichen FOSS-Prinzipien. Bei FOSS gibt man seinen Quelltext nicht frei, damit andere in diesem lediglich Lesen können, sondern, damit andere ihn in ihre Systeme integrieren können. Nutze ich z. B. den NetworkManager, der einen Connectivity Check durchführt, um zu erkennen, ob ich in das Internet komme, wird als Endpunkt meist ein von meinem Distributor bereitgestellter Server genutzt. Der Distributor ist es auch, dem ich mein ultimatives Vertrauen schenken muss, da dieser oft vorkompilierte Pakete bereitstellt. Ist ein Build nicht reproduzierbar, kann ich als Anwender nicht zweifelsfrei feststellen, ob lediglich die Inhalte ausgeführt werden, die auch angegeben sind. Unter diesem Aspekt ist der Umstand, dass der Distributor durch oben genannte Connectivity Checks meine IP-Adresse erfahren kann, fast zu vernachlässigen.

Freie Open Source Programme sind somit nur Bausteine, die von einem Intermediär aufbereitet und zur Verfügung gestellt werden. Somit sollte es aus meiner Sicht faktisch keinen Durchgriff von FOSS-Maintainern auf die Endnutzer geben, sofern nicht ein triftiger Grund dafür spricht.

Ein solcher triftiger Grund wären in meinen Augen Crashdumps: stürzt ein Programm ab, bieten einige Programme die Möglichkeit an, hilfreiche Daten zur Crash-Ursache (Tracebacks, Umgebungsvariablen, etc.) an die Hersteller zu melden. Oftmals wird dem Nutzer hier die Wahl gelassen, ob er diese Informationen mit den Entwicklern teilen möchte.

FOSS-Geschäftsmodelle

Freilich ist es schwierig, Geschäftsmodelle bei einer solch schwierigen Beziehung zwischen Softwarehersteller und -anwender zu etablieren. Dabei ist die „letzte Meile“ zwischen Distributor/OEM und Endkunden am attraktivsten, da dort Support verkauft werden kann. Beste Beispiele sind hier Red Hat und SUSE. Red Hat wurde für 34 Milliarden US-Dollar an IBM verkauft und der in Deutschland ansässigen SUSE GmbH steht am 19. Mai ein mit 5,7 Milliarden Euro bewerteter Börsengang bevor. Das bloße Schaffen und (entgeltliche) Zurverfügungstellen von Softwarequelltext und den Binaries wird heutzutage immer unattraktiver.

Fazit

Was Audacity angeht, bin ich optimistisch. Am Ende kann der Anwender nur gewinnen: entweder wird die Software verbessert oder es bildet sich ein Fork (wie schon geschehen), der die Nutzerschaft übernimmt.

Audacity ist eine Software, die ihren Zweck erfüllt. In meinen Augen kein Anwärter für Designauszeichnungen, aber plattformübergreifend und funktional.

Trotzdem muss man schauen, wie sich Audacity nun weiterentwickelt. Meine Prognose ist, dass die nächste Änderung, die ähnliche Kritik hervorruft, ein Auto-Updater wie bei MuseScore sein wird. ;-)

Uniswap v3 erfolgreich gestartet

07. Mai 2021 um 17:56

Uniswap v3 ging vor einigen Tagen an den Start. Dabei handelt es sich um eine Plattform, die ohne zentrale Börse den Austausch von Token-Paaren (z. B. ETH gegen DAI) über Smart Contracts ermöglichen soll. Diese Plattform werden auch als Decentral Exchange (DEX) bezeichnet und sind in der DeFi-Welt zu verorten.

Hayden Adams, der Initiator, hat nun gestern Abend auf Twitter verkündet, dass der Start der dritten Version des Systems besonders erfolgreich war: so wurde Uniswap v3 am ersten Tag mehr gehandelt als Uniswap v2 im gesamten ersten Monat.

Es gibt allerdings Kritik, die in zwei Richtungen geht:

  1. Die Verarbeitungsgebüren für die Ethereum-Transaktionen, die teilweise vom Design des Smart Contracts abhängen, sind weiter angestiegen. So kann eine Transaktion schnell um die 100 Euro an „Überweisungsgebühren“ kosten. (Q)

  2. Die neue Version bringt deutlich mehr Komplexität mit. Möchte man Geld einem Pool hinzufügen, genügte es hier, das Geld dort einzuzahlen. In Version 3 müssen verschiedenste Parameter eingestellt werden, deren Wirkung erst erlernt werden muss, um sinnvoll zu handeln. (Q)

Uniswap und DeFi bleiben weiterhin also interessant.

Weitere Links

Schnitzeljagd für Netzwerkprobleme

06. Mai 2021 um 13:40

Heute bin ich auf eine interessante Webseite gestoßen: https://mysteries.wizardzines.com/. Hier sind momentan vier „Fälle“ verfügbar, die sich allesamt mit typischen oder weniger bekannten Netzwerkproblemen beschäftigen. Das wären:

  • The Case of the Slow Websites
  • The Case of the Connection Timeout
  • The Case of the DNS Update that Didn't Work
  • The Case of the 50ms Request

Ich habe mir die Puzzles heute angeschaut und bin begeistert, weil es Netzwerkthemen auf eine Art und Weise abseits von Lehrbüchern und Q&A-Seiten einem näher bringt.

Man wird vor ein Problem gestellt, das es zu lösen gilt. Dabei stehen einem verschiedene Mittel zur Verfügung, die interaktiv aufgerufen werden können. Das ganze Spiel ist geführt gestaltet, sodass man nicht alleine gelassen wird und man gleichzeitig verschiedene Werkzeuge kennenlernt, die zur Problemlösung herangezogen werden können. An einigen Stellen wird man selber nach Problemlösungen, Kommandozeilenprogrammaufrufen (strace, tcpdump, ...) gefragt, die allerdings in vielen Fällen nur informativ sind und keinen großen Einfluss auf das Spiel haben.

Wie so oft führen viele Wege nach Rom, so auch bei den hier angesprochenen Fällen. An vielen Stellen ist Zusatzwissen zu finden, das über den Hintergrund aufklärt. Am Abschluss eines jeden Falls wird die Ursache erläutert.

Ich werde nicht weiter die konkreten Fälle spoilern, sie sind auf jeden Fall ganz nett. Besonders in der Netzwerkwelt ist es schwierig, zu debuggen, weil es keine klassische statische Analyse wie aus der Softwareentwicklung gibt. Gerade erst habe ich wieder einen Fall gehabt, bei dem ein Port an einem VLAN-fähigen Switch konfiguriert werden sollte. Access Port konfigurieren reichte scheinbar nicht aus, denn seltsamerweise kam nur ein Teil der Pakete durch. Die Lösung war, dass noch die PVID für den Port konfiguriert werden muss. Das Debugging wird dahingehend erschwert, dass Dinge gerne mal einfach „nicht funktionieren“ und keine Fehler werfen. Um Probleme zu lösen ist es wichtig, Muster zu erkennen und diese zu bewerten. Und genau darauf zielen die Mysteries ab.

Aus diesem Grund ist es wichtig, immer in der Übung zu bleiben, und da kann ich mir solche Spiele gut als Lernwerkzeug vorstellen, auch, wenn sie nicht aktiv auf einem System arbeiten.

Der Source für das Projekt ist auf GitHub verfügbar.

Django 3.2 veröffentlicht

10. April 2021 um 16:26

Anfang der Woche wurde das Webframework Django in Version 3.2 veröffentlicht. Der LTS-Release bringt einige Neuerungen, Breaking Changes und Abkündigungen von Funktionen mit.

Neuerungen

Die AppConfig ist seit vielen Versionen ein wichtiger Bestandteil von Django, um Projekte in Apps zu strukturieren. Die apps.py tritt in der normalen Entwicklung normalerweise eher in den Hintergrund, übernimmt aber entscheidende Aufgaben. Dies trifft insbesondere auf besonders austauschbare Applikationen zu. Wer eine default_app_config gesetzt hat, sollte allerdings bei Django 3.2 aufhorchen: Django 3.2 kann automatisch die AppConfig ermitteln, wenn in der App eine apps.py mit einer einzigen AppConfig existiert. Damit wird die nun veraltete Variable default_app_config nicht mehr benötigt.

Weiterhin lässt sich der standardmäßige Typ des Primärschlüssels ab sofort zentral anpassen. Ein Primarschlüssel wird automatisch mit dem Typ AutoField immer dann angelegt, wenn kein Feld mit primary_key=True in einem Model vorhanden ist. Sollte der Typ über die ganze App oder gar das ganze Projekt verändert werden, musste bisher jedes Model einzeln einen benutzerdefinierten Typ bereitstellen. Mit der globalen Einstellung DEFAULT_AUTO_FIELD sowie der anwendungsweiten Einstellung AppConfig.default_auto_field lässt sich das nun zentral ändern. Weiterhin wird für neu erstellte Projekte als automatischer Primärschlüsseltyp BigAutoField eingestellt, sodass die Primärschlüssel 64-bit statt bisher 32-bit große Integer speichern. Das ist besonders dann hilfreich, wenn von einem Model mehr als 2 Milliarden Instanzen abgespeichert werden sollen.

Die dritte große Änderung betrifft ebenfalls die Models: so ist es nun möglich, funktionelle Indizes über den positionsabhängigen Parameter *expressions anzulegen.

Der @admin.display-Dekorator ermöglicht es nun, für Property-Funktionen wie is_published direkt aus dem Model heraus die Darstellung auf der Adminoberfläche, die nun ein Dark Theme unterstützt, zu definieren. Weiterhin leitet die Adminoberfläche in jedem Fall unangemeldete Benutzer auf die Anmeldeseite weiter, um nicht durch Statusmeldungen (z. B. Not Found) Aufschluss über die Existenz von Objekten zu geben.

pymemcache wird nun ebenfalls unterstützt, sofern es in Version 3.4.0 installiert ist.

Das in Django 3.1 eingeführte JSONField besitzt nun auch mit JSONObject ein Pendant für Datenbankoperationen.

Wer einen Blog betreibt, kann mit Django besonders einfach RSS-Feeds für Models, hier konkret Artikel, erstellen, indem er auf das mitgelieferte django.contrib.syndication zurückgreift. Nun ist es möglich, mit item_comments direkt einen Link auf eine Kommentarsektion von Models zu spezifizieren, was in einigen RSS-Readern wie Tiny Tiny RSS an gesonderter Stelle angezeigt wird, um schneller in die Kommentare zu springen. Auf diese Änderung bin ich besonders stolz, weil ich sie selber beigetragen habe. ;)

Inkompatibilitäten

Die neue DatabaseFeatures.introspected_field_types ersetzt eine Reihe alter Features wie can_introspect_autofield, etc.

In der Adminoberfläche wird nun bei den Seiten ab 1 statt wie bisher ab 0 gezählt.

Abkündigungen

Die Unterstützung von PostgreSQL 9.5, MySQL 5.6 sowie PostGIS 2.2 wurde entfernt.

Verfügbarkeit

Django 3.2 unterstützt Python 3.9 bis 3.6. Die Unterstützung ist mindestens drei Jahre ab Veröffentlichung gewährleistet. Der vorherige LTS-Release 2.2 wird die Unterstützung nächstes Jahr im April 2022 verlieren.

Die Auflistung aller Änderungen samt Verweise und Codebeispiele ist in den Django 3.2 release notes verfügbar.

KDE Qt 5 Patch Collection angekündigt

06. April 2021 um 13:10

Wie ich bereits vor einigen Wochen berichtet habe, wurde Qt in Version 6 veröffentlicht. Dies hat auch Signalwirkung für eines der wichtigsten in Qt umgesetzten Projekte, KDE. Auch hier wird in den nächsten Monaten auf Qt 6 umgestellt.

Offene Fragen gab es bisher beim Support des auslaufenden Qt 5-Versionsstrangs, der die Grundlage für alle aktuellen KDE-Projekte bildet. Hier hat The Qt Company die Daumenschrauben angezogen (LinuxNews und ich berichteten) und den LTS-Support, der jetzt für die letzten Qt 5-Version 5.15 relevant werden würde, für die kommerziellen Kunden vorbehalten.

KDE kündigte heute nun an, eine eigene Qt 5 Patch Collection bereitzustellen, um den Übergang abzusichern.

Mit dieser Patch Collection werden Sicherheitsprobleme, Abstürze und Funktionsdefekte gelöst. Für die Entwicklung gelten gesonderte Bedingungen im Bezug auf die Verfahrensweisen für die Aufnahme von Patches, veröffentlicht wird aber weiterhin unter der gleichen Lizenz wie der von der Qt Open Source Edition. Releases wird es von dieser Patch Collection allerdings nicht geben. Die Repositories für die Patch Collection sind im KDE-eigenen GitLab verfügbar.

Ist man selber Entwickler von Qt 5-Anwendungen, sollte man im Hinterkopf haben, dass diese Patch Collection speziell auf KDE zugeschnitten ist. Ist der Umstieg auf Qt 6 bei KDE abgeschlossen, wird diese Patch Collection auch eingestellt. Wie aus der Pressemitteilung hervorgeht, zeigt der Hersteller von Qt Verständnis bei den Bemühungen. Man kann davon ausgehen, dass KDE trotz des Lizenztrubels in den letzten Monaten weiterhin gut im Kontakt mit The Qt Company steht. KDE betreibt eine spezielle Intermediärsorganisation mit der The Qt Company: die KDE Free Qt Foundation. Sie kümmert sich um Lizenzbelange und stellt sicher, dass weiterhin eine frei verfügbare Version von Qt für das KDE-Projekt zur Verfügung steht.

Google gewinnt Prozess gegen Oracle

05. April 2021 um 19:58

Heute ist es nun soweit: das lang erwartete Urteil im Verfahren zwischen Google und Oracle ist gefallen. Im Kern ging es um die Einordnung von Application Programming Interfaces (API) und Copyright (hier: Fair Use) in einem speziellen Fall.

Google hat für Android in früheren Versionen auf Java-APIs zurückgegriffen, die von Sun Microsystems entwickelt wurden, das von Oracle 2009 aufgekauft wurde. Oracle sah sich in seinen Rechten verletzt, Google argumentiert, dass die ursprüngliche Nutzung unter Fair Use fällt. Zwischenzeitlich hat Google auf eine rechtlich sicherere Variante umgestellt und nutzt nicht mehr das originale API.

Die Frage, inwiefern APIs urheberrechtlich geschützt werden können, ging schon durch mehrere Gerichtsinstanzen. Während zwei District-Gerichte für Google urteilten, hat der Federal Circuit beide Urteile aufgehoben. Der Supreme Court hat nun als letzte Instanz die finale Entscheidung getroffen. In einer 6:2-Entscheidung wurde heute mitgeteilt, dass Googles Nutzung der APIs unter Fair Use fiel.

Die heutige Entscheidung ist wegweisend für Open Source-Projekte, weil eine Entscheidung für Oracle einschneidende Konsequenzen im Bezug auf Interoperabilität von Programmen hätte – einer Gefahr, der sich die Richter bewusst waren, wie aus dem Statement hervorgeht. Wired hat sich dies vor einigen Jahren schon einmal angesehen und angeführt, dass auch Linux mit der POSIX-API Probleme bekommen hätte. Diese Entscheidung ist allerdings auch kein Freifahrtschein, da es in dieser Instanz nicht mehr um die Schutzfähigkeit von APIs generell ging, sondern eher um die Zugänglichkeit von Fair Use in diesem speziellen Fall. Das Fair Use-Prinzip beschränkt sich auf das US-Urheberrecht.

Wer sich weiter zu dem Thema informieren möchte, kann sich das Dokument vom Supreme Court, die Nachricht von CNN sowie den Artikel von Wikipedia zu dem gesamten Fall in allen Facetten durchlesen.

❌