Die Desktopumgebung KDE hat angekündigt, ab Plasma 6.8 vollständig auf Wayland zu setzen und die Unterstützung für X11 einzustellen. Mit dem Erscheinen dieser Version Anfang 2027 endet damit dort nach rund 30 Jahren die Ära des klassischen X-Fenstersystems.

KDE folgt damit anderen großen Projekten wie GNOME oder Distributionen wie Fedora, die X11 bereits zugunsten von Wayland aufgegeben haben. Erste technische Vorbereitungen erfolgten bereits mit Plasma 6.4, als die X11- und Wayland-Releases von KWin separiert wurden.

Ein kurzer Überblick

Wayland wird seit 2008 entwickelt und verfolgt das Ziel, den in die Jahre gekommenen X-Server abzulösen. Unter X11 versteht man sowohl das zugehörige Netzwerkprotokoll als auch dessen Referenzimplementierung. Als Fenstersystem implementiert X11 eine vollständige Client-Server-Architektur für die Verwaltung grafischer Objekte, die Synchronisation von Eingaben und die Aushandlung von Rendering-Pfaden, wobei es als Bindeglied zwischen Anwendungen, Grafiktreibern und der eigentlichen Display-Hardware fungiert. Das System blickt auf eine über 40-jährige Geschichte zurück und entstand in einer Zeit, in der grafische Unix-Desktops noch kaum verbreitet waren.

Diese historische Last führte zu hoher Komplexität im Protokoll und einer sehr großzügigen Vertrauensarchitektur: Viele Komponenten dürfen ohne separate Berechtigungsprüfung auf Eingabe- und Ausgabedaten zugreifen. Genau dieses Modell ist heutzutage ein Sicherheitsrisiko, etwa weil Malware unter X11 …

Die Webseite des Ubuntu-Derivats Xubuntu wurde kürzlich manipuliert und lieferte Malware aus. Wer also in den vergangen drei Wochen etwas von der Webseite heruntergeladen hat, sollte nochmal nachschauen, was er sich denn konkret heruntergeladen hat. Nach jetziger Erkenntnis wurde wohl eine Windows-Malware (.exe) verbreitet, konkret ein sog. Crypto-Clipper, der nach dem Einnisten die Zwischenablage manipuliert, damit Kriminelle sich in Kryptowährungstranskationen als Empfänger eintragen.

Die Malware wurde zwar somit über die offiziellen Wege verteilt, aber ließ sich für den geübten Nutzer noch unterscheiden. Schlimmer wäre es gewesen, wenn eine manipulierte ISO-Datei verteilt worden wäre.

Aber was schützt uns überhaupt davor? Diese Frage ist tatsächlich gar nicht so einfach zu beantworten, wenn wir davon ausgehen müssen, dass Angreifer Zugang zur Homepage der Distribution erhalten.

Denn effektiv fällt die Checksum bzw. der Hash, sei sie MD5, SHA1, SHA256, SHA512, als Kriterium raus. Sie wird immerhin über den gleichen Weg übermittelt wie der Download selber und kann somit mitmanipuliert werden. Checksums eignen sich allenfalls zur Überprüfung, ob der Download vollständig ist. Damit erfüllen wir das Sicherheitsziel Integrität, aber nicht Authentizität.

Die richtige Antwort lautet natürlich Signatur, meist in Form einer GPG-Signatur, und birgt gleichzeitig eine neue Frage in sich: woher weiß …

Kurz notiert: in den letzten beiden Tagen gab es einige Nachrichten vom Linux-Kernel.

Zuallererst wurde der Kernel in Version 6.17 veröffentlicht. Die Änderungen führen einerseits bessere Steueroption zur Auswahl von Prozessormitigationen, Live-Patching auf 64-Bit Arm sowie einige Verbesserungen an Dateisystemen wie ext4 und Btrfs ein. Die historische Sonderbehandlung von Einprozessorsystemen (ohne SMP) wird rückgebaut. Wer an allen Änderungen im Detail interessiert ist, kann einen Blick in die entsprechenden LWN Artikel oder bei LinuxNews werfen.

Apropos Dateisysteme: das jüngst aufgenommene bcachefs, um das sich vor und während seines Aufenthaltes im Mainline-Zweig viele kontroverse Diskussionen ergaben, wird Mainline im nächsten Release (6.18) voraussichtlich wieder verlassen. Torvalds kündigte im Commit zur Entfernung an, dass es als DKMS-Paket ausgeliefert werden soll.

Damit endet allerdings sicherlich auch die Maßgabe, dass die Module, von denen bcachefs abhängig ist, auf das Dateisystem abgestimmt werden. Hier gab es genau Streit, weil die Änderungen, die Kent Overstreet erwartet hatte, von den zuständigen Maintainern äußerst kritisch aufgenommen wurden. Ob die Änderungen in den anderen Modulen nun wieder zurückgesetzt werden, bleibt abzusehen.

Vor ziemlich genau drei Wochen wurde Debian 13 mit dem Codenamen "trixie" veröffentlicht. Da Debian einen wichtigen Architekturzweig unter Linux bildet, von dem viele Derivate wie z. B. Ubuntu abzweigen, werfen wir heute einen kleinen Blick auf die Veränderungen.

Zahlen, Daten, Fakten

Schaut man in die Veröffentlichungsmeldung, bekommt man einen Überblick, was sich in diesem Release getan hat:

Das Release umfasst nach gut zwei Jahren Entwicklung 69.830 Pakete, wobei 14.100 Zugänge, 8.840 Abgänge und 44.326 Aktualisierungen zu verzeichnen sind. Als Kernel kommt Linux 6.12 LTS zum Einsatz. Gebaut wird mit GCC 14.2 und LLVM 19. Systemd wird in Version 257 genutzt. Bei den Desktopumgebungen sind wir bei GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0 und Xfce 4.20 angekommen. Python wird in Version 3.13, Rust in Version 1.85, OpenSSL in Version 3.5 und PHP in Version 8.4 ausgeliefert. Das gesamte Paketarchiv umfasst 403 GB, wovon auf den meisten Systemen nur ein Bruchteil installiert sein sollte.

Zu den Architekturen:

• Die offizielle 32-Bit-Unterstützung (i386) entfällt ab diesem Release. Verbleibende i386-Pakete für Anwendungen sind nur zur Nutzung auf einem 64-Bit-System mit entsprechendem 64-Bit-Kernel vorgesehen, Stichwort multiarch.
• Für ARM-Nutzer alter Architekturen vor Arm v7, die auf die armel (ARM …

Kurz notiert: Die GNU C Library (glibc) wurde in Version 2.42 veröffentlicht. Der Fokus lag besonders auf Mathefunktionen aus neueren C-Standards, der Einführung von SFrame und der Entfernung des alten termio.h-Headers. Hier eine Auswahl neuer Features in aller Kürze:

• Neue Mathefunktionen, darunter:
  • Einige Funktionen aus der neuen ISO C23 werden nun von math.h unterstützt. In dieser Version kommen konkret Funktion für Potenzen und absolute Werte hinzu.
  • unsigned Abstandfunktionen wie uabs() werden unterstützt.
  • Neue Funktionen wie tanpif() wurden aus dem CORE-MATH-Projekt eingeführt.
• Die Unterstützung für die SFrame ist neu. Sofern mit den ebenfalls frisch veröffentlichten Binuntils 2.45 und dem Flag --enable-sframe gebaut wird, kann das neue Stack-Frame-Information-Format genutzt werden.
• Auf Linux gibt es nun die Funktion pthread_gettid_np() zum Anzeigen der Kernel Thread ID für einen Thread, siehe auch Diskussion.
• termios.h unterstützt nun beliebige Baud-Raten.
• Der tcache von malloc() unterstützt nun das Caching großer Blöcke.
• Die S390-Architektur erhält Unterstützung für die z17-Plattform.

Folgende Features werden entfernt oder betreffen die Kompatibilität:

• termio.h, das seit POSIX.1 aus 1988 veraltet galt, wird entfernt. termios.h ist der Ersatz.
• glibc.rtld.execstack unterstützt nun einen Kompatibilitätsmodus, mit dem Programme einen ausführbaren Stack mittels dynamisch geladener Bibliotheken anfordern können.
• Unterstützung für die TX Lock Elision von pthread …

Kurz notiert: Let's Encrypt hat Anfang des Monats am 4. Juni 2025 den Dienst für die E-Mail-Benachrichtigungen abgeschaltet. Zertifikatsinhaber werden fortan nicht mehr per E-Mail auf ein Auslaufen der Zertifikate hingewiesen. Diese Änderung wurde bereits im Januar angekündigt.

Begründet wird die Entscheidung durch die Kosten für den E-Mail-Versand, die Speicherung der E-Mail-Adressen sowie die Komplexität der Infrastruktur. In der Tat ist der Versand der Benachrichtigungen in einer Größenordnung wie bei Let's Encrypt sehr kostenintensiv, zumal dies über externe Dienstleister abgewickelt werden muss.

Die Speicherung der E-Mail-Adressen ist ein interessanter Punkt, weil insbesondere bei certbot die Adressen standardmäßig immer abgefragt wurden, während man die Angabe bei acme.sh schon länger vermeiden konnte. Dies soll, so mein Verständnis, nun der Standard werden, da Let's Encrypt nicht mehr die E-Mail-Adressen der Zertifikatsinhaber speichern möchte. Für andere Zwecke wurden die E-Mail-Adressen offenbar auch nicht gespeichert, da z. B. das Zurückziehen eines Zertifikates (Revocation) über andere Wege wie den Private Key oder DNS-Verifikation läuft, wie in der Dokumentation beschrieben wird.

Bleibt noch ein letzter Punkt, der im Blogartikel zur Abschaltung angeführt wird: Ein integraler Bestandteil von Let's Encrypt ist Automatisierung. Schon von Anfang an wurden automatisierte Verfahren wie ACME statt einer manuellen Verifikation eingesetzt, …

Zum Ende des Monats wollte ich euch noch im Blog von der aktuellen Risikozone-Episode 74 „SIP Happens: No Contact, No Service“ berichten, in der wir uns endlich mal dem Session Initiation Protocol (SIP) widmen konnten. Unsere Gäste von sipgate arbeiten im Infrastrukturteam und sind damit die richtigen Ansprechpartner.

SIP war insbesondere in den 2000ern ein Ding, als VoIP aufkam und ist dann in meinen Augen immer mehr in den Hintergrund verschwunden. Unter der Haube wird die Rolle von SIP in den nächsten Jahren jedoch immer wichtiger, da SIP die technische Grundlage für Anrufe im Mobilfunk darstellt. Anrufe werden spätestens ab der in 2028 beginnenden GSM-Abschaltung in Deutschland entweder per Mobilfunk über VoLTE oder per WLAN über VoWiFi abgewickelt. Intern kommen dabei immer IPsec und SIP zum Einsatz.

Festnetztelefonie ist seit der All-IP-Umstellung um 2018 herum auch weitestgehend SIP-only. Nur stellt sich hier die Frage, wie lange uns klassische Telefone erhalten bleiben, bis alles in Teams & Co. migriert wird. SIP ist somit so ein wenig die Schnittstelle zwischen der Internetwelt mit der Best-Effort-Mentailität und der klassischen Nachrichtentechnik, wo es auf Qualität der Kanäle ankommt.

Als Bonus berichten wir über eine Lücke in der Firmware einiger Smartphones, die auf MediaTek-Prozessoren setzen. …

Kurz notiert: das Team von Oligo Security berichtet von einer Reihe an Schwachstellen, die sie im AirPlay Protokoll und AirPlay SDK gefunden und "AirBorne" getauft haben. Insgesamt 23 Schwachstellen, die zu 17 CVEs geführt haben, wurden zutage gefördert.

Einer der schwerwiegendsten Lücken umfasst eine Zero-Click RCE, sodass ein erfolgreicher Exploit ohne Interaktion mit dem Nutzer beliebigen Code ausführen kann. Die Lücken wurden spätestens mit iOS 18.4 sowie den aktuellen Versionen der unterstützten macOS-Releases (15.4, 14.7.5, 13.7.5) gefixt.

Wer sich für die Apple-Wireless-Protokolle interessiert, kann gerne auch die Risikozone-Podcastepisoden 60 und 61 hören, wo wir mit Alexander Heinrich über die Findings im AWDL- und AirDrop-Protokoll gesprochen haben.

Kurz notiert, weil ich es ganz spannend finde: Wer kann am besten die Anti-Spam-Mechanismen wie DMARC, SPF und DKIM erfüllen? Genau, Spammer. Damit ist – auch im Lichte der unterschiedlichen Anstrengungen der großen Provider zur Durchsetzung der Einträge – die Spamerkennung anhand Überprüfung der Authentizität des Absenders hinfällig.

Hintergrund ist, dass das E-Mail-System eigentlich wie ein System von Briefkästen aufgebaut ist. Jemand schreibt eine E-Mail und wirft sie in einem „Briefkasten“, der das SMTP spricht, ein. Anschließend findet die E-Mail den Weg zum Ziel, wo sie entweder abgeholt (POP3) oder zwischengespeichert (IMAP) wird. In diesem gesamten Konzept ist der Absender eher informativ und allen Beteiligten ist eigentlich klar, dass dieser gefälscht werden kann.

Offene Briefkästen, in die alle etwas einwerfen können, werden auch als Open Relay bezeichnet und sind heutzutage verpönt. Die wenigsten E-Mail-Server nehmen E-Mails von Open Relays an, weil sie – zu Recht – als Spamschleudern gelten.

DMARC, SPF und DKIM sind aber nicht als Spamschutz gedacht, sondern als Mechanismus, um die Legitimität von Absendern zu beweisen. Es hindert Spammer nicht daran, eigene Domains aufzusetzen, von denen sie legitim E-Mails versenden können. Es hindert nur Spammer, die Spam im Namen eines Anderen versenden.

Die Wirksamkeit ist im Übrigen …