Kurz notiert: Das Debian-Projekt hat sich in einer Abstimmung mit dem Einsatz von generativer KI im Projekt beschäftigt. Zur Debatte stand, ob und wie die Regeln angepasst werden sollen, ob ein Verbot kommen soll oder der Einsatz begrüßt wird. Das betrifft nicht nur Code, sondern auch Kommunikation wie Bug Reports oder Beiträge auf Mailinglisten.

Acht Vorschläge für den Umgang mit Gen AI standen zur Abstimmung, diese reichten von "No LLM contributions to Debian via Social Contract", also ein nachdrückliches Verbot, bis hin zu "Allow AI-Assisted Contributions with conditions". Darüber hinaus waren auch moderate Optionen vertreten.

Die durchaus moderate Option "Responsible Use of Generative AI" hat sich schließlich in der Präferenzwahl durchgesetzt.

Kurz zum Wahlverfahren, da gibt es nämlich einen spannenden Einblick. Da bei Debian-Abstimmungen die Wähler mit einer Rangfolge inkl. der Sonderoption "Keine der genannten Optionen" (also Ablehnung aller Wahloptionen) abstimmen, lässt sich ablesen, dass ein AI-Ban extrem schlecht ankam. Die beiden kritischen ablehnenden Optionen 1 und 3 landeten sogar hinter "Keine der genannten Optionen".

Die damit einhergehende Diskussion wurde - trotz des moderaten Ergebnisses - durchaus kontrovers geführt. Einerseits ist das Debian-Projekt, das sich traditionell stark für freie Software einsetzt, mit den lizenzrechtlichen Auswirkungen konfrontiert. Denn die LLMs nutzen …

Wenn ich mir überlege, dass die heutige Generation Tablet gar nicht mehr in den Kontakt mit Dateisystemen kommt, keine ausführbaren Dateien kennt und nun auch auf Android vom Sideloading befreit wird, sehe ich auch ein Stück Computergeschichte verloren: Die Zeit der Virenscanner. Diese waren in den 2000ern kaum wegzudenken. Viele der verbreiteten Scanner verwandelten sich dann irgendewann zu Bloatware und ab 2015 mit dem Aufkommen von Windows Defender und dem Siegeszug der mobilen Endgeräte verschwanden sie allmählich in ihrer bisherigen Form. Viele der AV-Hersteller haben sich dann auf Endpoint Security und Mobile Device Management konzentriert. Auf den beiden großen mobilen Plattformen iOS und Android gibt es durch das Sandboxing und die regulierte App-Verteilung sowieso Bedingungen, unter denen das Konzept des Virenscanners einfach nicht mehr funktioniert.

Was aber auch zur goldenen Ära der Virenscanner dazugehörte, war das Argument, dass es Viren auf Linux nahezu nicht gäbe. Das System habe von Haus eine strikte Rechtevergabe und da die Verbreitung des Systems im geringen Prozentbereich liegt, ist es für Angreifer schlicht zu irrelevant für die Entwicklung, als dass es ein lohnenswertes Ziel sei.

AUR

Diese Erklärung greift allerdings zu kurz, wenn wir die aktuellen Beobachtungen im Arch User Repository (AUR) einbeziehen. Angriffswellen …

Kurz notiert: Besonders schätze ich an KDE, dass die Konfigurationsoptionen über die Jahre so erhalten geblieben sind. Das betrifft insbesondere die Möglichkeit, die Themes und Panels umfangreich anzupassen. Dadurch konnte man noch lange das Oxygen- und Air-Theme nutzen, das eigentlich zu KDE 4 gehörte.

Trotzdem hat man über die Jahre gespürt, dass die Themes effektiv in die Jahre kamen und einige technische Neuerungen nicht mehr zurückportiert wurden. Während die eckigen unpassenden Hintergründe in den Textfeldern noch verkraftbar waren, wurde Dolphin zunehmend schwieriger zu nutzen und auf der Arbeitsfläche funktionierten auch viele Widgets nicht mehr. Das hat dazu gehört, dass ich teilweise schon begann, auf Breeze umzustellen. Ich habe schon vermutet, dass das Theme über kurz oder lang aus dem Source Tree entfernt wird.

Anfang des Jahres kam dann aber die überraschende Nachricht, dass anlässlich des 30-jährigen KDE-Jubiläums auch die alten Themes restauriert werden sollen.

Das Ergebnis wird nun mit Plasma 6.7 veröffentlicht und wird im verlinkten Blogartikel umfangreich vorgestellt. Ich habe das aktualisierte Theme schon ausprobiert und bin begeistert, dass die alten Themes wieder so gut funktionieren und an die neuen Gegebenheiten angepasst wurden. Auch wurde das Icon-Set überarbeitet. Am Refresh hat sogar der ursprüngliche Oxygen-Entwickler Nuno Pinheiro …

Als Black Swan bezeichnet man Ereignisse, die erst unvorstellbar erscheinen, dann die Welt verändern und im Nachhinein unvermeidlich wirken: Man hätte es doch wissen müssen.

LLMs in der Softwareentwicklung fühlen sich wie so ein Ereignis an, wenn man sich die Geschwindigkeit und Breite der Adaption und ihre Auswirkungen anschaut. Die Erwartung war: Robotik übernimmt erst körperlich schwerere Aufgaben, Automatisierung übernimmt dann die mühsamen, repetitiven Aufgaben und irgendwann wird Programmierung durch No-Code-Werkzeuge verborgen. Was stattdessen passiert, ist das Gegenteil von No-Code: eine Maschine, die unendlich viel Code ausspuckt und den Programmierer als quasi „den“ White-Collar-Beruf imitiert. Aus No-Code wird More-Code. Dadurch wird ausgerechnet zuerst der Programmierer zur Zielscheibe: Die teuren Positionen geraten unter Druck - und das auch noch zuerst.

Anders gefordert

Wer mit diesen Tools arbeitet, merkt schnell: Man kommt schneller zu Ergebnissen. Auch bei komplexen Anfragen, auch auf bestehenden Codebases.

Die kognitive Arbeit verschiebt sich dabei, sie verschwindet nicht. Früher hat man während des Schreibens ein mentales Modell aufgebaut und die Lösung entstand beim Denken in Code.

Heute bekommt man Code, den etwas anderes gedacht hat. Man muss dieses fremde Modell verstehen, beurteilen und einordnen. Das fordert nicht weniger, nur anders.

Vicki Boykis beschreibt es gut: es wird immer …

Großflächige Linux-Updates sind angesagt: Auch wenn CVE-2026-31431 „nur“ mit CVSS 7.8 eingestuft wird, hat die Lücke aufgrund ihrer Verbreitung es in sich. Forscher von Xint konnten im cryptography-Subsystem einen Logikfehler identifizieren, der es einem einfachen Benutzer ermöglicht, eine 4-Byte-Schreibsequenz im Page Cache jeder lesbaren Datei vorzunehmen.

Der „Copy Fail“ getaufte Angriff funktioniert dabei so ähnlich wie Cache Poisoning. Da Dateien unter Linux im RAM gecached werden, um Mehrfachzugriffe auf die Festplatten zu reduzieren, kann ein Angreifer, der es schafft, diesen RAM-Inhalt zu kontrollieren, Einfluss auf Dateiinhalte nehmen. Normalerweise geht das nicht direkt, da der Kernel prüft, ob auch Schreibrechte vorliegen. In diesem Fall kann das umgangen werden.

Die Gefahr der Rechteausweitung ergibt sich durch die Manipulation von setuid-Binaries wie su oder sudo, die automatisch als root ausgeführt werden, aber deren gehärtete Logik unautorisierten Zugriffen normalerweise standhält. In diesem Fall wird aber der Inhalt der Binary durch den o. g. Cache-Angriff so manipuliert, dass die Angreifer ohne jegliche Zugriffsprüfung Root-Rechte erlangen.

Besondere Gefahr ergibt sich für Container-Umgebungen. Da zwei isolierte Container sich trotzdem denselben Kernel teilen, ermöglicht der Angriff potentiell auch Container-Breakouts.

Ein Fix liegt bereits vor, die betroffenen Kernel-Versionen reichen bis in das Jahr 2017 zurück. Das Xint-Team …

Kurz notiert: In den vergangenen Tagen gab es unterschiedliche Fälle von Supply-Chain-Angriffen auf verschiedene Pakete, die unmittelbar das Ziel hatten, wie ein Trojaner insbesondere Credentials abzugreifen. Dabei hat es sowohl das Paket litellm als auch axios getroffen.

LiteLLM: Snyk hat vergangene Woche einen umfangreichen Bericht veröffentlicht, der beschreibt, wie die Versionen 1.82.7 und 1.82.8 für den LLM-Proxy-Server LiteLLM durch den Threat-Actor, der als TeamPCP bezeichnet wird, manipuliert werden konnten. Besonders hierbei war, dass die Payload als .pth-Datei im Rahmen eines Python-Startup-Hooks ausgeliefert wurde und entsprechend verschleiert war.

axios: Heute hat es dann den im JavaScript-Ökosystem bekannten HTTP-Client axios getroffen. Wie StepSecurity und Aikido schreiben, wurde hier der Maintainer-Account übernommen, sodass zwei bösartige Versionen veröffentlicht werden konnten: 1.14.1 und 0.30.4. Mit der Größe von axios handelt es sich hier offenbar um einen der schwerwiegensten npm-basierten Supply-Chain-Angriffe bisher.

In beiden Fällen haben sowohl PyPI als auch npm die betroffenen Versionen wenige Stunden nach Veröffentlichung geflaggt. Trotzdem dürfte es einige Entwickler erwischt haben, die ihr gesamtes System nun als kompromittiert betrachten sollten. Da speziell im Fall von axios die Malware aktiv ihre Spuren entfernte, ist die Eingrenzung der kompromittierten Komponenten auf einem betroffenen System stark erschwert.

In einer der nächsten Risikozone-Episoden werden …

sudo-rs hat sich zum Ziel gesetzt, einen Ersatz für das klassische sudo bereitzustellen. Dabei setzt das Projekt auf Rust, um eine "safety oriented and memory safe implementation" zu realisieren.

Hintergrund

Kurz zum Hintergrund: sudo unterscheidet sich von normalen Kommandos dadurch, dass das setuid-Flag der Binary gesetzt ist und das Programm beim Aufruf direkt mit Root-Rechten gestartet wird. Die Privilege Escalation ist wiederum die Voraussetzung dafür, dass ein Nutzer nach erfolgreicher Authentifizierung Root-Rechte annehmen kann. Sind jedoch im sudo-Programm selbst Bugs vorhanden, wird die Rechteerweiterung zum Sicherheitsrisiko. Wichtig an dieser Stelle: Privilege Escalation bezeichnet zunächst nur die Technik. Sie tritt häufig als Folge von Sicherheitslücken auf, hat aber auch legitime Einsatzszenarien.

Die gesamte Sicherheit hängt also von den Werkzeugen ab, die über setuid-Privilegien verfügen. Genau hier möchte sudo-rs ansetzen und eine Implementierung anbieten, die vom Speichersicherheitsmodell von Rust profitiert, um das Risiko bisher unentdeckter Sicherheitslücken in der Speicherverwaltung zu reduzieren.

Neue Darstellung von Passwörtern

Dass sudo-rs kein vollständiges Drop-in-Replacement wird, zeigt die Änderung, dass Passwörter nun standardmäßig in der Konsole maskiert angezeigt werden. Bisher hat sudo jegliche Ausgabe unterdrückt.

Administratoren, die dieses Verhalten abstellen wollen, können Defaults !pwfeedback in die sudoers-Datei einfügen. Das ist insbesondere dann relevant, wenn andere Programme davon …

Kurz notiert: Die Data-Science-Bibliothek pandas wurde in Version 3.0 veröffentlicht. Auch wenn ein drittes Major-Release erst einmal nach tiefgreifenden Änderungen klingt, ist es tatsächlich nur die SemVer-Versioierung, die für den Major-Release verantwortlich ist, da pandas 3.0 auch ältere Features entfernt, die zuvor deprecated wurden. An sich bleiben natürlich die Grundkonzepte gleich.

Neuerungen

Das pandas-Team hebt drei Neuerungen hervor:

Automatischer String-Typ für Spalten

Wird ein DataFrame erzeugt, ermittelt pandas in vielen Fällen den Datentyp für die Spalte. Wenn z. B. nur Ganzzahlen enthalten sind, ist der Datentyp int. Bei Strings war dies bisher nicht so, wie wurden als der generische Datentyp object aufgelöst und mussten manuell typisiert werden.

Das wird mit pandas 3.0 gelöst, denn String-Spalten erhalten nun automatisch den Typ str. Für diese Umstellung wird ein Migration-Guide bereitgestellt.

Verbesserungen bei Copy-on-Write

Unter Python gibt es eigentlich keine Pointer, womit man sich eigentlich einige Probleme erspart. Trotzdem kann es Referenzen geben, die wie Pointer wirken. Ein Beispiel aus dem Guide:

df = pd.DataFrame({"foo": [1, 2, 3], "bar": [4, 5, 6]})
subset = df["foo"]
subset.iloc[0] = 100

Aus der 1 in "foo" wurde kurzerhand 100, auch wenn nicht der DataFrame direkt geändert werden musste. Das Verhalten …

Das Jahr 2026 steht bevor und ich möchte die Gelegenheit nutzen, um mich bei allen Lesern zu bedanken, die mich auch in diesem Jahr begleitet haben: sowohl auf meinem Blog als auch auf dem Risikozone-Podcast.

Den eigentlichen Jahresrückblick gibt es in der heute erschienenen Risikozone-Episode 90. Dort haben wir schon festgestellt: Abgesehen von ein wenig Cloudflare-„Schluckauf“ war es ein vergleichsweise ruhiges Jahr.

Mit zwölf Artikeln konntet ihr in diesem Jahr jeden Monat etwas von mir lesen. Der Schwerpunkt lag allerdings klar auf dem Podcast: dort kamen noch einmal 26 Episoden dazu.

Für das nächste Jahr – und nebenbei dem Jahr des zehnjährigen Blogbestehens – nehme ich mir vor, den Blog endlich wieder stärker anzupacken, ein paar Neuerungen einzuspielen und vielleicht auch thematische neue Inhalte auszuprobieren. Wie bei vielen OSS-Projekten ist es oft nicht so leicht, dafür konsequent Zeit zu finden - aber gerade deshalb eignet sich der Blog gut für spannende Experimente.

Bis dahin wünsche ich euch einen guten Rutsch in das neue Jahr. Mögen eure Builds stabil sein und die Bugs reproduzierbar (oder am besten gar nicht existieren). Auf ein gutes 2026!