Anmelden
(Bild: lapandr / Shutterstock.com)
Im neuen Release können Developer experimentell ohne Speech-Erweiterung in VS Code diktieren und erhalten tiefere Einblicke in Subagents.
Microsoft bringt in Visual Studio Code 1.131 neue Funktionen für den LLM-Einsatz und bietet die Möglichkeit, in Chat, Editor und Terminal zu diktieren, ohne eine zusätzliche Erweiterung zu installieren. Wer sich auf die Suche macht, kann zudem ein kleines Haustier im Chatfenster entdecken.
Zum Ausführen von komplexen Aufgaben können Entwicklerinnen und Entwickler Agenten Tasks an Subagents delegieren lassen. Diese laufen parallel in ihrem eigenen Kontextfenster. Nun können Developer im Agents-Fenster genauere Informationen über die Unteragenten sehen, ohne die entsprechende Konversation öffnen zu müssen. Die Hauptkonversation zeigt für laufende Subagents ihr verwendetes Modell, ihre Ausführungsdauer und die durch sie aktiv aufgerufenen Tools an.
(Bild: Microsoft)
Subagents lassen sich auswählen, um in ihrer eigenen Konversation in einem anderen Chat den vollständigen Fortschritt anzusehen. Dabei bleibt die Hauptkonversation verfügbar.
Bislang war die VS Code Speech Extension notwendig, um die Diktierfunktion in VS Code nutzen zu können. Nun ist ein eingebauter Transkriptionsservice als experimentelles Feature enthalten. Er ermöglicht es Entwicklern, in Chat, Editor und dem integrierten Terminal zu diktieren.
Dafür kommt gemäß Microsoft das private, offline laufende Nemotron-Modell zum Einsatz. Audioinformationen sollen auf dem Gerät verbleiben. Verfügbar ist das Feature für Windows x64 und Arm64, macOS auf Apple Silicon, Linux x64 und Arm64 mit glibc 2.34 oder neuer sowie in Remote Workspaces. Letzteres ist möglich, da die Transkription auf dem lokalen VS-Code-Client läuft. Noch nicht verfügbar ist die Diktierfunktion in der Web-Version von VS Code und auf Intel-basierten Macs sowie 32-Bit- und Arm32-Systemen.
Als experimentelles Gimmick ist nun ein Haustier in VS Code eingezogen. Entwicklerinnen und Entwickler finden es, wenn sie /vscode-pet im Chat eingeben. Per Maus können sie es verschieben und damit interagieren. Ganz neu ist die Idee nicht, denn im Visual Studio Marketplace [1] wimmelt es vor Erweiterungen für Hunde, Katzen, Pinguine und Co.
(Bild: Microsoft)
Weitere Informationen zu den Updates finden sich in der Ankündigung [2]. Neu erschienen ist darüber hinaus die aktuelle Insiders-Version 1.132 [3].
URL dieses Artikels:
https://www.heise.de/-11385363
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: iX)
Das Arch-Werkzeug Shelly wechselt von .NET zu Zig: Neue GUI, überarbeitete CLI und getrennte Flatpak-Unterstützung sollen es schlanker machen.
Das Paketwerkzeug Shelly ist in Version 3.0.0 erschienen. Die Entwickler haben Paketverwaltung, Kommandozeile, Schlüsselverwaltung und GTK4-Oberfläche weitgehend neu in Zig implementiert. Dadurch entfällt für die Hauptanwendung die verwaltete .NET-Laufzeit; zugleich kann Shelly native Bibliotheken direkter nutzen. Messwerte zu Startzeit und Ressourcenbedarf stehen allerdings noch aus.
Shelly ist ein grafisches und kommandozeilenbasiertes Werkzeug zur Verwaltung von Arch-Paketen. Es bindet neben den regulären Pacman-Repositories auch das Arch User Repository (AUR), AppImages und optional Flatpaks ein. Damit richtet sich das Projekt an Nutzer, die Software aus mehreren Quellen mit einer Oberfläche und einer Kommandozeile verwalten wollen.
Mit Version 3 [1] ersetzt Shelly seine bisherige C#-/.NET-Codebasis weitgehend durch Zig. Die bekannten Programme shelly und shelly-ui bleiben erhalten. Hinter ihnen steht jedoch eine weitgehend neue Codebasis. Auch das Werkzeug für die Schlüsselverwaltung wurde umgestellt: Das eigenständige Programm heißt nun shelly-key statt shelly-keys.
Zig passt zu Shelly vor allem, weil die Software native Schnittstellen wie libalpm, GTK4 und libarchive ohne eine zusätzliche .NET-Interop-Schicht direkt ansprechen kann. libalpm ist die Bibliothek, auf der Pacman, der Paketmanager von Arch Linux, aufsetzt. Die neue Implementierung spart damit die bisherige Vermittlung zwischen verwaltetem .NET-Code und nativen Bibliotheken weitgehend ein.
Zig verwaltet zudem Speicher und Ressourcen explizit: Die Release Notes heben klarere Besitzverhältnisse und besser vorhersehbare Lebenszyklen für Ressourcen hervor. Das soll die technische Grundlage robuster und leichter wartbar machen.
Auch die grafische Anwendung haben die Entwickler in Zig neu geschrieben. Sie bietet weiterhin Paketansichten als Liste oder Raster. Hinzu kommen sortierbare Spalten, Filter für installierte Pakete sowie ausführlichere Angaben zu Paketquellen und Abhängigkeiten.
Für das AUR überarbeitet Shelly unter anderem die Auswahl optionaler Abhängigkeiten, Vorschauen für PKGBUILD-Dateien und die Anzeige der makepkg-Ausgabe. Vor AUR-Updates kann Shelly nun alle geänderten PKGBUILDs gesammelt zur Prüfung anzeigen, bevor die Transaktion beginnt. Ein PKGBUILD legt fest, wie ein AUR-Paket aus seinen Quellen gebaut wird. Die Vorschau hilft Nutzern daher, Änderungen vor dem Paketbau nachzuvollziehen [2].
Die Fortschrittsanzeige für Aktualisierungen und Transaktionen soll auch längere Vorgänge darstellen, ohne die Oberfläche zu blockieren. Wartungsfunktionen bündelt Shelly auf einer neuen Seite für Dienstprogramme. Dazu zählen die Synchronisierung der Paketdatenbanken, das Beheben veralteter Sperrdateien, die Cache-Bereinigung und das Entfernen verwaister Pakete.
Die CLI wurde ebenfalls von Grund auf neu geschrieben. Sie behält sowohl ausgeschriebene Befehle als auch Pacman-ähnliche Kurzoptionen. Ein gemeinsamer Befehlskatalog dient als Grundlage für Hilfe, Dokumentation und Shell-Vervollständigungen. Neben Fish und Zsh kann Shelly nun auch Vervollständigungen für Bash erzeugen.
Mit shelly <Suchbegriffe> kann das Werkzeug die offiziellen Paketquellen und das AUR durchsuchen. Ausgewählte Treffer lassen sich anschließend direkt in den Installationsablauf übernehmen. Aktualisierungsprüfungen und Upgrades koordinieren reguläre Arch-Pakete, AUR-Pakete, AppImages und Flatpaks. Fehlt ein optionales Backend, sollen Aktualisierungen aus den übrigen unabhängigen Quellen dennoch weiterlaufen.
Weitere Updates gibt es beim Export und Import von Paketlisten im TOML-Format, Paketmarkierungen, Downgrades, Arch-News, Schlüsselringe, pacnew- und pacsave-Dateien sowie die Bereinigung des Paket-Caches. Für unterstützte Befehle bleibt eine strukturierte JSON-Ausgabe verfügbar. Das ist für Skripte verlässlicher als die menschenlesbare Standardausgabe, deren genaue Form sich durch den umfassenden Umbau geändert haben kann.
Flatpak-Unterstützung liefert Shelly 3 als separates Paket namens shelly-flatpak-backend aus. Wer ausschließlich Pacman, das AUR oder AppImages verwendet, benötigt damit keine Flatpak-Bibliotheken wie libflatpak, GLib/GIO und OSTree.
Shelly kommuniziert mit dem Zusatzmodul über eine ABI (Application Binary Interface). Das Hauptprogramm prüft die Version vor der Nutzung und soll inkompatible Backends sauber ablehnen. Ohne das Zusatzmodul bleiben die Funktionen für ALPM, AUR und AppImages ebenso verfügbar wie Hilfe, Versionsabfrage und Shell-Vervollständigungen. Bei Flatpak-Befehlen weist Shelly auf fehlende Voraussetzungen hin.
Wer Flatpaks weiterhin mit Shelly verwalten will, benötigt neben Flatpak selbst das genannte Paket shelly-flatpak-backend. Vorhandene Konfigurationsdateien haben Vorrang vor den neuen Standardwerten; unbekannte alte Felder ignoriert das Programm. Automatisierungen sollten die neue CLI-Hilfe prüfen und, wo verfügbar, auf JSON-Ausgaben umstellen. AUR-Builds in einem sauberen Chroot bleiben über die Kommandozeile verfügbar, die entsprechende Option fehlt jedoch vorerst in der grafischen AUR-Ansicht.
URL dieses Artikels:
https://www.heise.de/-11385187
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Nur wenn alle Gruppenteilnehmer den Chatverlauf detailliert vergleichen, haben sie eine Chance die, Manipulation zu erkennen.
(Bild: DavideAngelini/Shutterstock.com)
Alle Mitglieder eines Gruppenchats sollten dieselben Inhalte sehen. Die üblichen Chat-Dienste stellen das nicht sicher. Das ist riskant.
Gruppenchats der großen Messaging-Dienste Whatsapp, iMessage, Signal und Threema sind zwar gut Ende-zu-Ende-verschlüsselt, sodass Unbefugte nicht mitlesen können. Gegen Manipulation der angezeigten Inhalte in Gruppenchats sind sie aber nicht geschützt, wenn der Täter ein legitimes Gruppenmitglied ist oder das Gerät eines Mitglieds kontrolliert. Solchen Angreifern ist es möglich, Chatnachrichten zu senden, die die selbe Identifikationsnummer tragen, aber bei unterschiedlichen Empfängern unterschiedlichen Inhalt haben. Damit fällt die sogenannte transcript consistency: Die Chatteilnehmer haben plötzlich unterschiedliche Versionen des Chats und wissen das nicht.
Die falschen Mitteilungen können sogar in Zitaten anderer Chatteilnehmer erhalten bleiben, so dass ein Chatteilnehmer eine völlig falsche Vorstellung vom Chatverlauf haben kann. Beispiel: Die Chatrunde stimmt einem Vorschlag einhellig zu, doch ein Chatteilnehmer sieht Zustimmung zu einem völlig anderen Vorschlag. Oder: Ein böswilliges Gruppenmitglied schickt einen Hyperlink in die Runde, der zu einem lustigen Katzenbild führt. Nur einem Gruppenmitglied schickt der Täter einen Link, der Malwaredownload auslöst. Die Gruppe antwortet auf den lustigen Link mit Heiterkeit und Danksagung, was die Zielperson zum Klick auf den Link verleitet.
Oder: Die Einladung zu einem wichtigen Treffen ergeht für einen Teil der Teilnehmer für Montag, für andere, die der Angreifer lieber nicht dabeihaben möchte, für einen anderen Tag, nachdem bereits alle Beschlüsse gefasst sind. Oder: Den Moderatoren eines Chats werden stets lautere Inhalte gezeigt, während bestimmte Mitglieder mit unlauteren bedacht werden. Und so weiter und so fort.
Nutzt ein Teilnehmer unter dem selben Nutzerkonto mehrere Endgeräte für den Gruppenchat, können ihm unterschiedliche Inhalte auf unterschiedlichen Endgeräten zugemittelt werden (außer bei Threema, das dabei das Manko fehlender Forward Secrecy [1] aufweist). Auch die Unterdrückung einer Nachricht je nach Endgerät ist bei den drei anderen Diensten möglich. Das alles funktioniert, ohne Bruch von Verschlüsselung, nicht nur für Textmitteilungen, sondern auch für Multimedia-Inhalte. Zudem lassen sich Abstimmungen auf verschiedene Art und Weise manipulieren.
Das hat eine österreichische Gruppe aus IT-Sicherheitsforschern um Gabriel Gegenhuber herausgefunden und Anfang Februar den vier Kommunikationsdiensten gemeldet. Obwohl Gruppenchats inzwischen auch für (kriegs)wichtige politische Entscheidungen auf oberster Ebene genutzt werden, plant keiner der vier Betreiber unmittelbare Maßnahmen um das Grundproblem auszumerzen.
Ende-zu-Ende-verschlüsselte Gruppenchats können auf unterschiedliche Weise realisiert werden. Threema, iMessage und früher auch Signal setzen auf paarweise Kommunikation: Sendet ein Teilnehmer eine Nachricht an die Gruppe, schickt sein Client im Hintergrund tatsächlich jeweils eine Kopie der Nachricht an jeden anderen Teilnehmer. Je größer die Gruppe, desto effizienter ist das derzeit von Signal und Whatsapp eingesetzt Verfahren, bei dem nur eine Nachricht vom Client an den Server geht, der sie dann an die anderen Chatteilnehmer weiterleitet („server fan-out‟). Nur für die ursprüngliche Übermittlung der notwendigen Verschlüsselungsschlüssel kommuniziert der Absender direkt mit den anderen Kommunikationspartnern.
Die Forscher haben für die böswilligen Mitteilungen offizielle (Signal und Threema) respektive inoffizielle (Whatsapp, iMessage) Clients genutzt und durch Softwarepatches angepasst. Auf Empfängerseite kam die übliche Software der Messagingdienste für Android, iOS, Linux, macOS, Windows, sowie Webbrowser zum Einsatz.
Bei paarweiser Kommunikation in Gruppenchats, wie Threema und iMessage sie einsetzen, ist der Trick naheliegend: Der Absender schickt, unter Verwendung des selben Nachrichten-ID, einfach unterschiedliche Inhalte an unterschiedliche Empfänger. Signal unterstützt, wohl aus Gründen der Rückwärtskompatibilität, sowohl paarweise Kommunikation als auch server fan-out.
Zudem können Whatsapp und Signal trotz standardmäßigem server fan-out dazu gebracht werden, automatisch auf paarweise Kommunikation zurückzufallen. Das tritt ein, wenn ein Empfänger eine Nachricht nicht entschlüsseln kann. Er fordert dann eine neuerliche Übertragung in paarweiser Kommunikation, schließlich müssen ja nicht alle Gruppenteilnehmer die Nachricht noch einmal erhalten, nur weil einer an ihrer Entschlüsselung scheitert.
Und dieses Scheitern kann absichtlich ausgelöst werden: Wie erwähnt, nutzen Whatsapp und Signal paarweise Kommunikation zur ursprünglichen Übermittlung der Entschlüsselungsschlüssel. Dort setzt der Angreifer an: Er sendet dem Zielclient absichtlich einen Schlüssel, mit dem dieser die „normalen‟ Chatnachrichten des Absenders gar nicht entschlüsseln kann. Dann löst jede normale Nachricht einen Fehler mit der Bitte um neuerliche, direkte Zusendung aus. Daraufhin schickt der böswillige Absender die gefälschte Nachricht mit der ID-Nummer der echten Nachricht.
Doch auch im server-fan-out-Verfahren, bei dem der Client eine Nachricht an den Server schickt, der sie dann an die Gruppenmitglieder verteilt, ist Manipulation möglich. Die erwähnte Kann-ich-nicht-entschlüsseln-Fehlermeldung des Empfängers bittet zwar um neuerliche Zumittlung mit der paarweisen Methode. Doch diesen Teil der Bitte kann der Angreifer ignorieren und die verfälschte Nachricht als server fan-out absenden.
Dann geht die verfälschte Nachricht zwar an alle Gruppenmitglieder, deren Clients sehen aber die ID einer bereits erhaltenen Nachricht. Daher verwerfen sie die „Kopie‟ ohne Fehlermeldung und prüfen nicht, ob sie die neue Nachricht überhaupt entschlüsseln können. Nur die Zielperson erhält die falsche Nachricht, weil sie das Original nicht entschlüsseln konnte.
Aufgrund des besonders hohen Datenschutzes bei Signal gibt es dort noch einen zweiten Angriffsvektor: Während Whatsapp auf dem Server eine Liste aller Mitglieder einer Gruppe führt, tut Signal das nicht. Der Absender muss jeder Nachricht eine Liste aller Gruppenteilnehmer beilegen und kann dabei bestimmte Teilnehmer unter der Tisch fallen lassen. Sie erhalten diese Nachricht dann nicht, merken aber nichts von der Lücke.
Ist eine falsche Nachricht einmal zugestellt, bleibt sie auch in Zitaten erhalten, beispielsweise wenn andere Gruppenmitglieder darauf reagieren und ihre Meinung zu dem zitierten Inhalt kundtun. Denn die Zitatfunktion überträgt aus Gründen der Datensparsamkeit standardmäßig nicht den eigentlichen Inhalt, sondern verweist nur auf die ID der zitierten Nachricht. Damit sieht der Empfänger eines Zitats dabei also stets jene Nachricht, die ihm ursprünglich zugemittelt wurde, sei es das Original oder die falsche Nachricht.
Gibt es die referenzierte Nachricht nicht, verweigern Threema und iMessage das Zitat. Signal und Whatsapp fallen jedoch darauf zurück, den Inhalt des Zitats zu übermitteln. Das ist durchaus nützlich, den ein neu zur Gruppe Hinzugestoßener soll ja mitreden können. Allerdings eröffnet das dem Angreifer die Möglichkeit, den angeblich zitierten Inhalt beliebig zu definieren. Das geht auch in 1-zu-1 Chats, ohne Gruppe. Hier ist zu hoffen, dass der Empfänger noch weiß, was er (nicht) von sich gegeben hat.
Signal blendet unter den angeblich zitierten Inhalt immerhin einen Hinweis ein, dass es die zitierte Nachricht nicht finden kann. Bei Whatsapp fehlen solche Hinweise. Und speziell der Desktop-Client Signals erlaubt Zitate von Nachrichten, die erst nach dem Zitat verschickt werden.
Besonderen Spaß dürften die Forscher mit der Abstimmungs-Funktionen der vier Dienste gehabt haben. Keiner sichert die gestellte Frage kryptographisch ab. Bei iMessage, Signal und Threema kann ein Angreifer, der eine Abstimmung erstellt, unterschiedlichen Gruppenmitgliedern unterschiedliche Fragen stellen. Bei binären Fragen (ja/nein) unter Whatsapp, das Abstimmungen mittels Hash absichert, kann er die Antwortmöglichkeiten mit einander austauschen. Was der eine als Ja-Stimme erachtet, ist für den andern womöglich eine Nein-Stimme.
Zudem kann er bei Whatsapp bestimme Mitglieder von der Stimmenzählung ausschließen, in dem er etwa durch absichtliches Einfügen eines unsichtbaren Leerzeichens den Hashwert verändert. Stimmt der Hashwert dann nicht überein, verwirft Whatsapp die abgegebene Stimme einfach.
Bei Threema und Signal ist auch das Abstimmungsergebnis nicht sicher. Threema sieht vor, dass der Ersteller der Abstimmung den Stimmenstand allen Gruppenmitgliedern mitteilt. Da er einzelnen Mitgliedern verfälschte Nachrichten senden kann, kann er die angezeigten Stimmen einzelner Teilnehmer verändern, streichen oder hinzufügen.
Bei Signal verkündet zwar der Server das Abstimmungsergebnis. Doch kann der Angreifer im Voraus solche Mitteilungen erfinden und versenden. Das spätere, echte Abstimmungsergebnis wird von jenen Signal-Clients, die bereits ein gefälschtes Endergebnis erhalten haben, als vermeintliches Duplikat verworfen.
Dem nicht genug können auch die Abstimmenden Unfug treiben, indem sie unterschiedlichen Gruppenmitgliedern unterschiedliche Entscheidungen zusenden. Damit laufen die beim jeweilige Empfänger angezeigten Abstimmungsergebnisse auseinander. Bei Threema ist sogar möglich, mit manipulierten Nachrichten mehr als eine Stimme auf einmal in die Waagschale zu werfen, sowie versteckte Stimmen nachzureichen. Bei iMessage kann ein Täter im Namen anderer Gruppenmitglieder abstimmen.
Bei Whatsapp haben die Forscher entdeckt, dass iOS-Clients Abstimmungen anders verarbeiten als Android-Clients. Das können Angreifer ausnutzen, beispielsweise indem sie nur Gruppenmitglieder mit Android-Client abstimmen lassen. Gleichzeitig verrät Whatsapp, welcher Client genutzt wird. Das erlaubt unter Umständen Rückschlüsse auf den Aufenthaltsort des Teilnehmers, beispielsweise wenn er Whatsapp nur im Büro mit Windows nutzt, oder mit Linux nur Zuhause, oder umgekehrt.
Auseinanderlaufen von Inhalten von Gruppenchats ist für den einzelnen Teilnehmer schwer zu erkennen. Hinzu kommt, dass sensible Chats oft auf automatische Löschung der Inhalte nach kurzer Zeit setzen. Dadurch werden die Manipulationsbeweise automatisch vernichtet.
Das Grundproblem manipulierter Inhalte ist systembedingt, speziell paarweise Kommunikation eröffnet Lücken. Mit Verzicht darauf wäre viel erreicht, das würde aber aufwändiges Redesign erfordern.
Für Signal und Whatsapp, die primär auf server fan-out setzen und nur subsidiär auf paarweise Kommunikation zurückgreifen, haben die Forscher Vorschläge, wie die Probleme reduziert werden könnten: Verbot paarweiser Kommunikation, außer für die ursprünglichen Schlüssel, weil es dort im gegebenen Konzept notwendig ist. Clients sollten unerbetene, neuerliche Zusendungen von Nachrichten generell verwerfen. Bittet ein Client um neuerliche Zumittlung einer Nachricht, sollte das allen Gruppenmitgliedern mitgeteilt werden, um Aufmerksamkeit zu schaffen. Zeitstempel sollten nur vom Server akzeptiert werden, und jede Veränderung der Gruppenzusammensetzung sollte auf technischer Ebene zur automatisch Erstellung einer neuen Gruppe führen.
Vor allem aber sollten Vorgänge transparent gemacht werden: Fehlgeschlagene Entschlüsselung sollte ebenso angezeigt werden, wie neuerliche Zusendung einer früheren Nachricht – samt Warnung, dass der Inhalt einer solchen Nachricht von dem anderen Teilnehmern angezeigten Inhalt abweichen kann. Zudem sollte für jeden Gruppenteilnehmer automatisch eine Statistik geführt werden, die offenlegt, wo sich Entschlüsselungsfehler und neuerliche Versendungen häufen. Denn das ist verdächtig.
Ein anderer Weg wäre, die Ende-zu-Ende-Verschlüsselung auszuschalten, so dass jeder bei jedem alles mitlesen kann. Davon hält Studienautor Gegenhuber (früher an der Universität Wien, jetzt an der Interdisciplinary Transformation University in Linz tätig) nichts: „Ohne Ende-zu-Ende-Verschlüsselung ist man vollständig vom Server abhängig, und der könnte dann beliebig Nachrichten manipulieren oder unterdrücken. Außerdem könnte der Serverbetreiber alles mitlesen.‟
„Ende-zu-Ende-Verschlüsselung ist eine große und wichtige Errungenschaft‟, betonte Gegenhuber gegenüber heise online. „Dabei wird jedoch Vertrauen und die Verantwortung für Validierung vom Server zum Client verschoben. Und der kann bösartig sein. Daher ist transcript consistency wichtig.‟
Mit Gegenhuber haben Moritz Grefner, Matthäus Wininger, David Schmidt und Aljosha Judmayer (allesamt Universität Wien) sowie Maximilian Günther (SBA Research) die Sache erforscht. Sie haben ihr gemeinsames Paper unter dem Titel Send and Pretend: Exploiting Transcript Consistency Issues in End-to-End Encrypted Group Chats in der Nacht auf Donnerstag bei Github [3] und Zenodo online [4] gestellt. Dort stehen auch Programmcode und Beweisvideos zum Download bereit.
Gegenhuber, Günther und Judmayer waren bereits Teil jenes Forscherteams, das das gesamte Whatsapp-Nutzerverzeichnis abgeschnorchelt [5] hat. Zuvor waren die drei an einem Forschungsprojekt beteiligt, das gezeigt hat, wie die Verschlüsselung Whatsapps herabgestuft [6] werden kann, sowie an einem Projekt, das offengelegt hat, was Signal und Whatsapp trotz Verschlüsselung verraten [7].
Das Team hat alle vier Dienstebetreiber am 6. Februar informiert. Apple hat laut Forscherteam den Empfang bestätigt. Meta Platforms hat 1.000 US-Dollar Belohnung ausgeschüttet und Verbesserungen bei Abstimmungen in Whatsapp angekündigt. Threema möchte das Teilproblem der Möglichkeit zur Abgabe mehrerer Stimmen angehen.
Keiner der Drei hat demnach angekündigt, das Grundproblem fehlender transcript consistency in Gruppenchats anzugehen. Auch das von einer nichtkommerziellen Stiftung betriebene Signal plant keine Sofortmaßnahmen, möchte sich aber dann dem Problem widmen, wenn es gröbere Arbeiten an der Gruppenchat-Funktion in Angriff nimmt.
URL dieses Artikels:
https://www.heise.de/-11384095
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Matthias Parbel / iX / KI)
Stackable stellt die Data Platform 26.7 auf Qualität und Supply-Chain-Sicherheit um. Neben SLSA-Provenance drohen bei der Registry-Logik Breaking Changes.
Für die Veröffentlichung der neuen Version 26.7 seiner Stackable Data Platform weicht das gleichnamige Unternehmen vom üblichen Release-Rhythmus ab. Statt neuer Produktfeatures stand dabei laut Ankündigung die Qualitätssicherung der modularen, auf Kubernetes basierenden Open-Source-Plattform im Mittelpunkt. SDP 26.7 zeichnet sich demnach durch den Abbau technischer Schulden, die Stabilisierung von CI-Pipelines und das Bereinigen instabiler Tests aus. Die Verbesserungen reichen von der dynamischen Registry-Auswahl über erhöhte Supply-Chain-Sicherheit bis zum neuen zentralen Verzeichnis, dem Stackable Hub. Zwar liegen die wichtigsten Neuerungen somit eher unter der Oberfläche. Sie sollen aber insbesondere Betreibern regulierter Infrastrukturen und all jenen zugutekommen, die Operatoren außerhalb des Standardwegs installieren wollen.
Laut Blogbeitrag zum neuen Release [1] liefert Stackable dennoch eine Reihe von Updates, darunter Apache Airflow 3.2.2, Apache Superset 6.1.0, OpenSearch 3.6.0, Trino 481, Apache NiFi 2.9.0, Open Policy Agent 1.16.2 sowie die LTS-Versionen Apache Spark 4.1.2 und Apache Druid 37.0.0. Zudem wurden 133 Schwachstellen behoben – davon 10 kritische und 62 als hoch eingestufte CVEs. Unterstützt werden Kubernetes 1.31 bis 1.36 sowie Red Hat OpenShift 4.18 bis 4.22.
Die folgenreichste Änderung betrifft die Art, wie Operatoren ihre Produktimages beziehen. Bisher war die Registry oci.stackable.tech fest im Code hinterlegt. Anpassungen für Air-Gap-Umgebungen oder interne Mirror-Registries erforderten Helm-Werte pro Produkt oder Eingriffe in die Containerd-Konfiguration auf Knotenebene – ein Workaround, der mit wachsender Plattformgröße zunehmend unhandlich wurde.
Ab Version 26.7 ersetzt Stackable diese Logik durch einen konfigurierbaren Mechanismus. Über den neuen CLI-Parameter --image-repository beziehungsweise die Umgebungsvariable IMAGE_REPOSITORY bestimmen die Operatoren, woher sie ihre Produktimages beziehen. Wird ein Operator über den Helm-Chart oder das OLM-Manifest (Operator Lifecycle Manager) installiert, setzt die Plattform diesen Wert automatisch passend zur Registry, aus der der Operator selbst stammt. Ein Operator, der aus quay.io/stackable kommt, zieht seine Produktimages damit automatisch ebenfalls von quay.io. Stackable veröffentlicht seine Artefakte – inklusive der Operator-Helm-Charts – künftig direkt aus den CI-Pipelines nach quay.io, statt sie manuell zu spiegeln.
Für Installationen außerhalb von Helm oder OLM ist das ein echter Breaking Change. Wer Operatoren per eigenem Deployment-YAML, Kustomize oder ArgoCD betreibt, muss --image-repository explizit im args-Block des Operator-Containers setzen – etwa als --image-repository=oci.stackable.tech/sdp oder mit dem Pfad einer internen Mirror-Registry. Wer eigene Helm-Charts pflegt, muss zusätzlich den Wert image.repository anpassen: Er darf den Operatornamen nicht mehr enthalten. Statt oci.stackable.tech/sdp/airflow-operator lautet der Wert künftig nur noch oci.stackable.tech/sdp. Fehlt die Anpassung, finden die Operatoren ihre Images nicht mehr – die Pods bleiben mit ImagePull-Fehlern hängen. Ein Testlauf in einer separaten Umgebung vor dem Produktiv-Upgrade ist dringend empfohlen.
Unterm Strich wandert die Registry-Portabilität damit von produktspezifischen Workarounds in die Plattformlogik. Für Air-Gap-Szenarien lässt sich IMAGE_REPOSITORY gezielt auf eine interne Registry lenken, sofern die Produktimages konsistent dorthin gespiegelt sind – ein Gewinn für souveräne, interoperable Architekturen.
Der zweite große Themenblock ist die Supply-Chain-Sicherheit. Ab Version 26.7 liefern alle Container-Images von Stackable – sowohl Produkt- als auch Operator-Images – eine SLSA-Build-Provenance-Attestation (Supply-chain Levels for Software Artifacts [4]). Die Provenance (Herkunft) entsteht über den slsa-github-generator und erreicht SLSA Level 3: Ein vertrauenswürdiger, vom Projekt-Build getrennter Builder erzeugt und signiert die Attestation, sodass ein kompromittierter Buildjob sie nicht fälschen kann. Signiert wird keyless über Sigstore mit GitHub Actions als OIDC-Identity-Provider.
Ergänzend zu den bereits vorhandenen CycloneDX-SBOMs hängt nun an jedem Image auch eine SBOM im SPDX-Format als OCI-Attestation. Zur Verifikation empfiehlt Stackable den slsa-verifier, der stets gegen die Digest-Referenz statt gegen Tags arbeitet. Alternativ lässt sich cosign einsetzen.
Für Betreiber in regulierten Sektoren wie dem Finanz- und Gesundheitswesen sowie der öffentlichen Verwaltung ist das mehr als eine Formalie. Anforderungen aus NIS2 [5], dem EU Cyber Resilience Act [6] oder ISO 27001 verlangen zunehmend den Nachweis, woher Software-Artefakte stammen und ob sie unterwegs manipuliert wurden. Mit der Provenance lässt sich für jedes Image belegen, aus welchem Git-Repository und Commit heraus es gebaut wurde und welche Build-Infrastruktur beteiligt war. Die SPDX-SBOMs erfassen jede enthaltene Bibliothek samt Version und damit die Grundlage für automatisierte CVE-Scans und Policy-Prüfungen. Admission-Controller wie Kyverno oder OPA/Gatekeeper lassen sich so konfigurieren, dass nur Images mit gültiger Signatur und passenden Attestationen in den Cluster gelangen.
Neu ist der Stackable Hub unter hub.stackable.tech. Der öffentliche, schreibgeschützte Katalog ist als zentrale Anlaufstelle für alle Fragen rund um SDP-Releases gedacht – und schließt damit eine Lücke zwischen Dokumentation und tatsächlich ausgeliefertem Stand.
Der Hub bietet drei durchsuchbare Bereiche: eine Übersicht aller veröffentlichten SDP-Releases mit Erscheinungs- und End-of-Support-Datum, eine Komponenten-Timeline mit den exakten Versionen jedes enthaltenen Open-Source-Produkts sowie eine CRD-Referenz mit vollständigen .spec-Schemas, die sich nach SDP-Release filtern lassen. Wer wissen will, welche Apache-Kafka-Version in Release 25.11 enthalten war oder wie das Schema eines TrinoCluster-Objekts in Version 26.3 aussieht, findet die Antwort dort ohne Deployment.
Für Tooling und Automatisierung steht eine CORS-fähige JSON-API unter /api/v1/ bereit, ohne Authentifizierung, direkt einbindbar in CI-Jobs, Skripte und MCP-Server. Zusätzlich steht für LLM-Tools ein llms.txt-Endpunkt als Klartext-Zusammenfassung des Hubs bereit, damit ein Assistent aktuelle SDP-Daten in den Kontext einordnen kann, anstatt Versionsnummern zu erraten. Der bisherige CRD- und SBOM-Browser soll künftig in den Hub überführt werden.
Den drei zentralen Neuerungen ist eines gemeinsam: die dynamische Registry-Auswahl, SLSA-Provenance mit SPDX-SBOMs und der Stackable Hub lassen die Stoßrichtung des Anbieters erkennen, zu noch mehr Nachvollziehbarkeit und Portabilität der Plattform. Weniger Abhängigkeit von fest verdrahteten Defaults, dafür mehr kryptografisch prüfbare Herkunftsnachweise und maschinenlesbare Metadaten für die eigene Automatisierung. Ein kompletter Überblick aller Änderungen in SDP 26.7 findet sich in den Release Notes [7].
URL dieses Artikels:
https://www.heise.de/-11380921
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Moritz Förster / KI / iX)
Gmail REST API, Microsoft Graph und JSON Schema: Himalaya 2.0 richtet die Mail-CLI stärker auf Automatisierung aus.
Die Kommandozeilen-Mailsoftware Himalaya 2.0.0 unterstützt Gmail über die Gmail REST API sowie Outlook- und Microsoft-365-Postfächer über Microsoft Graph. Neben den klassischen Verfahren IMAP und SMTP erhält das Projekt so Zugriff auf Funktionen wie Gmail-Labels und -Threads sowie Graph-spezifische Ordner-, Nachrichten- und Anhangsoperationen.
Himalaya ist ein in Rust geschriebener, zustandsloser E-Mail-Client für die Shell. Er bündelt mehrere Backends hinter einer gemeinsamen Befehlsoberfläche, darunter IMAP, SMTP, JMAP, Maildir und m2dir. Die Software richtet sich vor allem an Nutzer, die E-Mail-Funktionen aus Skripten, Terminal-Workflows oder eigenen Frontends heraus nutzen wollen; eine separate TUI befindet sich in Entwicklung.
Gmail- sowie Outlook- und Microsoft-365-Postfächer ließen sich schon vor Version 2.0.0 [1] über IMAP und SMTP einrichten. Neu ist daher nicht die grundsätzliche Kompatibilität mit diesen Anbietern, sondern der Zugriff auf deren jeweilige API. Die einheitlichen Mail-Befehle bleiben erhalten. Für Funktionen eines bestimmten Protokolls oder Anbieters stellt Himalaya zusätzliche Unterbefehle wie gmail und msgraph bereit.
Die Gmail-Anbindung deckt unter anderem Profile, Labels, Nachrichten, Anhänge, Entwürfe, Threads, Verlauf und Einstellungen ab. Das Graph-Backend bietet Zugriff auf Profile, Mail-Ordner, Nachrichten und Anhänge. Beide Backends authentifizieren sich mit einem OAuth-2.0-Bearer-Token.
Die Entwickler haben den Einrichtungsassistenten deutlich ausgebaut. Er erkennt erreichbare Dienste wie IMAP/SMTP, JMAP, Gmail und Microsoft Graph und fragt die passende Anmeldemethode anschließend in einem separaten Schritt ab. Bei IMAP und SMTP wählt der Nutzer einen SASL-Mechanismus wie PLAIN, LOGIN, SCRAM-SHA-256 oder OAUTHBEARER; bei JMAP stehen HTTP-Authentifizierungsarten wie Basic und Bearer zur Wahl.
Der Wizard testet IMAP- und SMTP-Verbindungen bereits während der Konfiguration. Schlägt die Anmeldung fehl, gibt Himalaya keine Konfiguration aus, die später ohnehin nicht funktioniert. Außerdem kann der Assistent bekannte Postfachrollen als Aliase vorbelegen. Bei JMAP ermittelt er sie direkt am Server, für Gmail und Microsoft Graph kennt er die festen Systemordner. Bei IMAP setzt er derzeit nur den Inbox-Alias automatisch.
Dadurch funktionieren Befehle ohne explizite Postfachangabe mit dem voreingestellten Inbox-Alias. Soweit das jeweilige Backend die Ordner kennt, lassen sich auch Ziele wie Gesendet, Entwürfe oder Papierkorb über sprechende Aliase angeben.
Der Aufruf ohne Unterbefehl hat sich allerdings geändert: himalaya startet nun den Wizard, statt wie bisher die Nachrichtenübersicht des Standardkontos anzuzeigen. Die erzeugte Kontokonfiguration gibt das Tool als TOML auf der Standardausgabe aus. Nutzer müssen sie selbst in ihre Konfigurationsdatei umleiten, etwa mit himalaya > ~/.config/himalaya/config.toml. Bestehende Installationen sollten daher bisherige Aufrufe und Skripte prüfen.
Für Automatisierungen führt Himalaya den Befehl json-schema ein. Er erzeugt für jeden Befehl mit strukturierter Ausgabe eine JSON-Schema-Datei, sofern das zugehörige Backend in die verwendete Himalaya-Version einkompiliert ist. Andere Programme können damit die JSON-Ausgabe validieren und daraus etwa in Python, Rust oder TypeScript typisierte Datenmodelle erzeugen.
Auch die Übergabe vollständiger MIME-Nachrichten vereinheitlicht die neue Version. Befehle zum Senden oder Speichern akzeptieren Nachrichten nun konsistent aus einer Datei, als direkt übergebenen Rohtext oder über die Standardeingabe. Externe Werkzeuge lassen sich dadurch leichter einbinden: Ein MIME-Generator kann eine Nachricht auf die Standardausgabe schreiben, Himalaya übernimmt anschließend den Versand oder speichert sie im gewünschten Ordner. Neu ist außerdem, dass messages send --save <POSTFACH> eine versandte Nachricht zusätzlich in einem ausgewählten Postfach ablegen kann. Mit messages add --send lässt sich eine eingelesene Nachricht speichern und zugleich versenden.
Für Spezialfälle bietet Version 2 zudem direkten Zugriff auf IMAP- und SMTP-Kommandos. Mit imap raw und smtp raw können Anwender Protokollbefehle ohne zusätzliche Verarbeitung an den Server senden. Das eignet sich für Tests, Fehlersuche oder proprietäre Erweiterungen, setzt aber genaue Kenntnisse der jeweiligen Protokolle voraus.
Himalaya kann nun über Unix-Sockets mit einem lokalen, bereits authentifizierten IMAP- oder SMTP-Proxy kommunizieren. Das eignet sich etwa für Setups mit einem vorgeschalteten Sitzungsproxy. Über den Unix-Socket handelt Himalaya keine eigene SASL-Authentifizierung aus. Ein Proxy wie sirup kann so eine bereits angemeldete Sitzung bereitstellen, sodass Himalaya für das Speicher-Backend keine zweite Verbindung aufbaut.
Die Entwickler haben außerdem die DNS-Auflösung im Wizard geändert. Bevor Himalaya auf Cloudflares Resolver 1.1.1.1 zurückfällt, nutzt es einen explizit konfigurierten Resolver oder den Resolver des Betriebssystems. Das kann verhindern, dass die für die Mailserver-Suche verwendete Domain an einen zusätzlichen externen DNS-Dienst geht. Zugleich hilft die Änderung in Netzen, die öffentliche Resolver sperren.
Version 2.0.0 streicht zugleich ältere Integrationswege. Himalaya entfernt die eingebauten Composer- und Reader-Konfigurationen sowie Befehle wie compose-with, reply-with und read-with. Für komplexere Entwürfe sollen Nutzer künftig externe Programme einsetzen, die MIME-Nachrichten erzeugen und ihre Ausgabe an messages send oder messages add übergeben.
Auch die IMAP-Befehlshierarchie wurde vereinfacht. Sie orientiert sich nun stärker an der flachen Befehlsliste des Protokolls. Statt tiefer verschachtelter Untergruppen stehen Verben wie select, create, append, store und fetch direkt zur Verfügung.
URL dieses Artikels:
https://www.heise.de/-11382819
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: VADZIM SHUBICH/Shutterstock.com)
JetBrains hat eine kritische Sicherheitslücke in TeamCity geschlossen. Angreifer können CI/CD-Pipelines kompromittieren und Befehle auf dem Server ausführen.
Eine kritische Sicherheitslücke bei TeamCity betrifft alle On-Premises-Versionen der Build‑ und Deployment‑Server. Sie erlaubt es Angreifern, CI/CD-Pipelines zu kompromittieren. JetBrains rät dringend zum Update und hat bereits entsprechende Updates bereitgestellt. Cloud-Kunden müssen nicht handeln.
Die am 10. Juli gemeldete Sicherheitslücke betrifft das TeamCity agent polling protocol. JetBrains stuft sie mit dem CVE-Eintrag (Common Vulnerabilities and Exposures) CVE-2026-63077 als kritisch [1] ein, mit einem CVSS-Score von 9.8/10. Zum Zeitpunkt der Veröffentlichung waren keine aktiven Angriffe bekannt, wie JetBrains in seinem Blogeintrag schreibt. [2]
Nutzen Bedrohungsakteure die Sicherheitslücke aus, können sie sämtliche Authentifizierungsmechanismen des Tools umgehen und anschließend beliebige Betriebssystembefehle auf dem Server ausführen. Je nachdem, welche Rechte der Serverprozess besitzt, kann ein erfolgreicher Angriff TeamCity‑Daten, Konfigurationen und gespeicherte Zugangsdaten offenlegen oder den Serverzustand manipulieren.
Die Serverversionen 2025.11.7 und 2026.1.3 [3] schließen die kritische Sicherheitslücke auf der Software-Build-Plattform. Sie lassen sich jeweils auch per automatischem Update [4] aufspielen. Zusätzlich stellt JetBrains ein Sicherheitspatch-Plugin [5] für Serverversionen ab 2017.1 zur Verfügung.
Um Cyberbedrohungen möglichst wenig Angriffsfläche zu bieten, empfiehlt JetBrains Entwicklerinnen und Entwicklern, den Zugriff auf On-Premises-Server auf vertrauenswürdige Netzwerke zu beschränken und die Server mit minimal erforderlichen Betriebssystemrechten zu betreiben. TeamCity‑Server sollten zudem auf dedizierten Hosts laufen, die von den Build‑Agenten getrennt sind.
Die On-Premises-Versionen von JetBrains' CI/CD-Server waren in der jüngeren Vergangenheit immer wieder Angriffen ausgesetzt, die zum Beispiel unter CVE-2024-23917 (CVSS 9.8) [6] und CVE-2024-27199 (CVSS 7.3) [7] verbucht sind.
URL dieses Artikels:
https://www.heise.de/-11381504
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Wolf Hosbach/iX/KI)
Die neue Version von MCP bringt Breaking Changes: Server müssen sich nicht mehr um Sitzungen kümmern – diese Arbeit fällt nun auf die Clients.
LF Projects stellt das Model Context Protocol (MCP) auf eine komplett zustandslose Kommunikation um. Mit der neuen Version, die heute erscheinen soll, entfallen Sessions und Handshakes zur Initialisierung. Auf diese Weise lassen sich Server wie herkömmliche HTTP-Dienste betreiben.
Durch den Wegfall des initialize-Handshakes und der zurückgegebenen Mcp-Session-Id lassen sich Anfragen nun unabhängig von dedizierten Serverinstanzen behandeln, um beispielsweise die Last einfacher durch ein Round-Robin-Verfahren auf mehrere zu verteilen. Der Kommunikations-Overhead, wie die Protokollversion oder die Fähigkeiten des Clients, muss nun bei jeder Anfrage in einem _meta-Feld übertragen werden, während Clients die Server-Fähigkeiten bei Bedarf jederzeit über die neue Methode server/discover abfragen können.
(Bild: LF Projects/MCP)
Derzeit sieht der Handshake wie folgt aus:
FreshRSS POST /mcp HTTP/1.1
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-11-25","capabilities":{},
"clientInfo":{"name":"my-app","version":"1.0"}}}
Der Server antwortet mit einer Session-ID:
POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}Im neuen Verfahren gibt es keine ID mehr und ein einfacher Aufruf genügt:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}
Das neue Verfahren [1] hat zur Folge, dass Clients unterbrochene Sitzungen komplett neu starten müssen. Die bisherigen Funktionen Roots, Sampling und Logging sind zudem als veraltet eingestuft und entfallen in einem Jahr. Für Input- und Output-Schemata von Tools dient jetzt der komplette Standard JSON Schema 2020-12 und erlaubt Bedingungen wie oneOf, anyOf oder allOf. Der Fehlercode für nicht gefundene Ressourcen ändert sich in JSON-RPC -32602.
Eine weitere Neuerung beschreibt HTML-Schnittstellen, die auf dem Host in einer Sandbox laufen. Der Host kann sich Schnittstellen im Vorfeld vor Anfragen holen und prüfen. Neu ist zudem ein Namespace-Identifier für Extensions: io.modelcontextprotocol.
Entwicklerinnen und Entwickler müssen einiges umstellen. Der Blog-Eintrag [2] betont: „Dieses Release enthält Breaking Changes. Wir haben nicht vor, dass das die Norm wird.“ Für Anbieter von Ressourcen vereinfacht das neue Protokoll den Aufwand: Sie müssen keine Sitzungen mehr verwalten und können die Last über Server verteilen sowie skalieren. Updates erfordern kein Löschen mehr von bestehenden Sessions. Clients müssen nun hingegen die Sitzungen selbst abbilden und in nachfolgenden Anfragen jeweils mitgeben.
Durch den Wegfall des Samplings wird der LLM-Anbieter selbst zur API-Schnittstelle und kann diese auch bepreisen. Das Logging muss jetzt beispielsweise über stderr oder OpenTelemetry geschehen.
URL dieses Artikels:
https://www.heise.de/-11380312
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Blinde Flecken in der Softwareentwicklung durch homogene Teams: Dagegen hilft Interdisziplinarität, wie Prof. Claudia Nass Bauer im Gespräch erläutert.
Wer gestaltet eigentlich die Software, die unseren Alltag durchdringt, und wessen Werte fließen dabei ein? Richard Seidl und Prof. Claudia Nass Bauer sprechen darüber, warum homogene Teams blinde Flecken produzieren, die keine böse Absicht sind, sondern einfach das natürliche Ergebnis, wenn immer dieselben Perspektiven am Tisch sitzen. Diversität in der Softwareentwicklung bedeutet, dass Teams Menschen aus unterschiedlichen Disziplinen, etwa Design, Psychologie oder Soziologie, einbeziehen – nicht nur Informatiker. Denn interdisziplinäre Teams treffen bessere Entscheidungen, weil sie blinde Flecken einzelner Perspektiven ausgleichen.
Im Gespräch geht es um unbewusste Denkmuster, um Kommunikationssysteme, die in männerdominierten Gruppen entstehen, und darum, wie agile Methoden mit kleinen Teams diesen Mustern entgegenwirken können. Claudia Nass Bauer stellt außerdem ein Forschungsprojekt vor, das Studentinnen aus Design, Psychologie und Sozialwissenschaften gezielt an Softwareentwicklung heranführt, weil viele von ihnen schlicht nicht wissen, dass sie dort einen echten Beitrag leisten könnten.
„Wenn nur eine Perspektive abgebildet ist, dann wird diese Perspektive ausgedrückt. Das sind die Produkte, die wir bauen.“ – Claudia Nass Bauer
Claudia Nass Bauer [2] ist Professorin für Design-Strategie an der Hochschule Mainz. Seit Beginn ihrer beruflichen Laufbahn arbeitet sie in interdisziplinären Teams an digitalen Lösungen und setzt sich engagiert dafür ein, Design und Software-Engineering in Forschung und Lehre zu verknüpfen. Ihr Schwerpunkt liegt auf der strategischen Entwicklung und Umsetzung innovativer Lösungen sowie auf Design- und Innovationsprozessen. Aktuell leitet sie an der Hochschule Mainz das Forschungsprojekt WiSE [3] (Activating Women in Software Engineering). Bereits seit 2006 ist sie zudem am Fraunhofer IESE tätig. Dort konzentriert sie sich auf die Entwicklung, Erprobung und Anwendung nutzerzentrierter UX-Methoden, insbesondere im Rahmen von Forschungs- und Beratungsprojekten für eine Vielzahl von Industriekunden aus unterschiedlichsten Domänen.
Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, welche die Qualität in der Softwareentwicklung steigern.
Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar [4].
URL dieses Artikels:
https://www.heise.de/-11379718
Links in diesem Artikel:
Copyright © 2026 Heise Medien
DeepSeek ändert seine Finanzpläne.
(Bild: Runrun2 / Shutterstock.com)
Das chinesische KI-Start-up DeepSeek setzt seine zweite Finanzierungsrunde aus. Über seine Pläne für einen Börsengang sagte es jedoch nichts.
Das chinesische KI-Unternehmen DeepSeek hat potenziellen Investoren mitgeteilt, dass es die Gespräche über seine zweite Finanzierungsrunde vorerst aussetzt. DeepSeek hatte erst im vergangenen Monat seine erste externe Finanzierungsrunde über rund sieben Milliarden US-Dollar [1] abgeschlossen – und wollte direkt nachlegen.
Das sei nun nicht mehr geplant, berichtet The Information [2] unter Berufung auf eine mit dem Vorgang vertraute Person. Die angestrebte Bewertung lag bei 500 Milliarden Yuan, was rund 74 Milliarden US-Dollar entspricht. Das wäre ein erheblicher Sprung gegenüber der Bewertung aus der ersten Runde, an der sich unter anderem Tencent und der Batteriehersteller CATL beteiligt hatten.
Kurz zuvor hatte sich der CEO Liang Wenfeng verärgert über den Leak von Informationen gezeigt. Ein Transkript eines Investorencalls des CEOs, der im Mai stattfand, kursierte vergangene Woche auf chinesischen Social-Media-Plattformen und X. In dem Gespräch legte Liang seine strategischen Prioritäten dar. Der CEO war Berichten zufolge verärgert über den Leak.
Die Entscheidung fällt zudem in eine Phase verschärften Wettbewerbs im chinesischen KI-Markt. Moonshot AI, ein chinesischer Konkurrent, hat mit seinem Open-Weight-Modell Kimi K3 [3] gerade für erhebliches Aufsehen gesorgt. Das Modell erreichte in Benchmarks Ergebnisse, die mit US-amerikanischen Frontier-Modellen konkurrieren können. Die Nachfrage nach K3 war so groß, dass Moonshot AIs Server innerhalb von 48 Stunden angeblich überlastet waren. Laut The Information hätten einige Investoren vergangene Woche bei DeepSeek nachgefragt, ob der Erfolg von Kimi K3 Auswirkungen auf die eigenen Pläne haben könnte.
Parallel zur Finanzierungsrunde bereitet das 2023 gegründete Unternehmen einen möglichen Börsengang [4]vor. Laut Bloomberg arbeitet DeepSeek mit Wirtschaftsprüfern daran, bis Ende Dezember 2026 einen Finanzbericht zu erstellen – eine Voraussetzung für einen IPO-Antrag.
Investoren rechnen dem Information-Bericht zufolge damit, dass die Gespräche über die zweite Finanzierungsrunde zu einem späteren Zeitpunkt wieder aufgenommen werden. Unklar bleibt, wie lange die Pause dauern wird.
URL dieses Artikels:
https://www.heise.de/-11379417
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: software-architektur.tv)
In dieser Episode diskutiert Eberhard Wolff mit Tom Asel und Daniel Sack darüber, wie EventStorming als Baustein der kollaborativen Modellierung funktioniert.
Wer in der Softwareentwicklung ein gemeinsames Verständnis für die Fachdomäne schaffen will, kommt an EventStorming kaum vorbei. Die Workshop-Technik hat sich in den vergangenen Jahren als Standard etabliert – doch in der Praxis reicht die Methode allein oft nicht aus. Wie sich EventStorming daher nicht als singuläre Methode, sondern als ein Baustein in einem größeren Repertoire kollaborativer Modellierung verstehen lässt, darüber diskutiert Eberhard Wolff in dieser Folge mit Tom Asel [1] und Daniel Sack [2]. Im Verlauf des Gesprächs zeigen sie konkret, welche typischen Fallstricke es gibt und weshalb Teams sich nicht blind auf das Format verlassen sollten.
EventStorming wurde von Alberto Brandolini im Umfeld von Domain-driven Design (DDD) entwickelt und ist im Vergleich zu anderen Verfahren bewusst leichtgewichtig. Die Methode kommt zunächst ohne Rechner aus: Teilnehmende visualisieren fachliche Abläufe mit farbigen Klebezetteln auf einer großen Wand. Orangefarbene Zettel stehen für Domain Events, also fachliche Ereignisse, blaue für Commands, die diese Ereignisse auslösen, gelbe für Aggregates. Weitere Farben markieren Policys, Read Models, beteiligte Personen, Systeme oder sogenannte Hotspots – Stellen, an denen es hakt oder Klärungsbedarf besteht.
Ihre Erfahrung geben die drei Experten Sack, Asel und Wolff auch in Trainings unter dem Kürzel COSMO (Collaborative Software Modeling) bei Techtalk [3] und Socreatory [4] weiter.
Die Ausstrahlung findet am Dienstag, 28. Juli 2026, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite [6] einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt [7], der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer [8] (Socreatory) und Ralf D. Müller [9] (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als vier Jahren berichtet iX (heise Developer) über die Episoden.
URL dieses Artikels:
https://www.heise.de/-11379053
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Daniel Tadevosyan / Shutterstock.com)
Aus Sicherheitsgründen wartet das GitHub-Tool nun drei Tage bis zum Erstellen von Pull Requests, wenn Versionsupdates für Dependencies erscheinen.
GitHub hat angekündigt, dass sein Dependency-Update-Tool Dependabot eine Cooldown-Phase von drei Tagen erhält. Das heißt, erst nach diesem Zeitraum erstellt das Tool einen Pull Request für Versionsupdates von Dependencies. Hierdurch soll das Risiko für die Installation von manipulierten Packages sinken, denn solche Supply-Chain-Attacken treten immer wieder auf, werden jedoch meist innerhalb von Stunden entdeckt.
In einer größeren Sicherheitsattacke erlangte im September 2025 [1] ein Angreifer Zugriff auf den npm-Account eines Entwicklers und verbreitete darüber mit Malware versehene Pakete. Betroffen waren rund 20 npm-Pakete, darunter chalk und debug, mit mehr als zwei Milliarden Downloads pro Woche. Die Schadpakete waren etwa zwei Stunden lang verfügbar, bevor sie entdeckt und von npm entfernt wurden.
Um solche Szenarien einzudämmen, wartet das GitHub-Tool Dependabot [3] nun mindestens drei Tage, bevor es einen Pull Request für ein Versionsupdate einer Dependency erstellt. Diese standardmäßig eingestellte Zeitspanne können Entwicklerinnen und Entwickler nach Bedarf verkürzen oder verlängern.
GitHub begründet seine Wahl von drei Tagen damit, dass viele schadhafte Pakete bereits innerhalb von Stunden nach ihrer Veröffentlichung entdeckt werden. Das belegt beispielsweise ein von GitHub zitierter Bericht über 21 größere Supply-Chain-Vorfälle [4] in einem Zeitraum von acht Jahren zwischen 2018 und 2026.
Von der Änderung ausgenommen sind Security-Updates. Damit sind solche Updates gemeint, die sich auf eine bekannte Vulnerability beziehen und mit einem veröffentlichten Advisory für das Package einhergehen. In diesem Fall gibt Dependabot einen Alert aus und eröffnet einen Pull Request für das Update auf die gepatchte Version – ohne Verzögerung.
Weitere Informationen zum neuen Dependabot-Verhalten sind in einem GitHub-Blogeintrag zu finden [5]. Dabei weist GitHub darauf hin, dass die Cooldown-Phase lediglich eine von mehreren Sicherheitsschichten sein sollte, da sie beispielsweise gegen länger angelegte Attacken mit nicht aktivierten, unentdeckten Backdoors in Releases nichts ausrichten kann.
URL dieses Artikels:
https://www.heise.de/-11378632
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Das Debian-Projekt diskutiert über den grundsätzlichen Umgang mit LLM-Nutzung. Die Vorschläge für eine neue Generalresolution reichen von Verbot bis Erlaubnis.
Das Debian-Projekt [1] diskutiert über eine Generalresolution zur Nutzung von großen Sprachmodellen (LLM). Die Debian-Entwickler sind aufgerufen, sich zu entscheiden, wie sie mit generativer KI im Projekt der traditionsreichen Linux-Distribution umgehen wollen. Zur Auswahl stehen gleich vier konkurrierende Textvorschläge, die von einem vollständigen Verbot KI-gestützter Beiträge bis zu einer klar geregelten Zulassung reichen.
Die Auseinandersetzung ist nicht neu: Bereits 2024 lief auf der Debian-Projekt-Mailingliste eine ausgedehnte Debatte über KI-generierte [2] Inhalte, angestoßen von Tiago Bortoletto Vaz, der auf die restriktive KI-Policy von Gentoo [3] verwies. Ein Jahr später scheiterte der erste Versuch einer Generalresolution, welche klären sollte, ob KI-Modelle konform zu den Debian-Richtlinien für Freie Software (DFSG) sind. Der Initiator zog seinen Vorschlag zurück. Anfang 2026 bereitete das Projekt eine Resolution mit dem Arbeitstitel „Allow AI-Assisted Contributions“ vor, entschied sich dann aber zunächst dafür, nicht zu entscheiden und KI-Beiträge weiterhin fallweise zu handhaben. Die Entwürfe zur aktuellen Debatte finden sich auf der offiziellen Abstimmungsseite von Debian [4] wieder.
Der erste Vorschlag (Proposal A), eingebracht von Matthias Geiger, verlangt ein ausdrückliches Verbot sämtlicher Beiträge, die mithilfe großer Sprachmodelle oder anderer generativer KI-Werkzeuge entstehen. Der Geltungsbereich umfasst Debian-Quellpakete, projekteigene Software wie den Paketprüfer Lintian, Webressourcen, von Debian-Mitwirkenden erstellte Dokumentation und Übersetzungen sowie die offizielle Kommunikation des Projektes. Nicht betroffen sind Upstream-Projekte, KI-bezogene Software selbst und Upstream-Patches.
Als Begründung führen Geiger und seine Mitstreiter an, das Debian für Stabilität stehe, während viele LLMs eher den Ansatz „move fast and break things“ vertreten. Neben bekannten Qualitätsproblemen durch Halluzinationen entstehen Probleme etwa auch, wenn LLMs Paketinhalte generieren, die auf veralteten Methoden basieren oder alte und neue Praktiken inkompatibel miteinander gemischt werden. Eine Analyse zur Node.js-Debatte zeigt: Ein generelles KI-Verbot in Open-Source-Projekten [5] ist kaum durchsetzbar und ersetzt keine verantwortungsvolle Governance. Hinzu kämen unklare Urheberrechts- und Lizenzverhältnisse. Zudem sei Debian mehr als nur Code. Mit LLM-Nutzung würden Projektneulinge wenig lernen und könnten mittelfristig überarbeitete Maintainer nicht ersetzen. Zuletzt führen die Verfasser des Vorschlages ethische Bedenken an.
Verankert werden soll das Verbot als neuer Punkt im Debian-Gesellschaftsvertrag – wobei die Antragsteller einräumen, dass die Durchsetzung schwierig bleibt und primär auf den guten Willen der Community setzt.
Gänzlich in eine andere Richtung geht der Vorschlag (Proposal B) vom ehemaligen Debian-Projektleiter Lucas Nussbaum. Dieser erlaubt KI-gestützte Beiträge unter sechs Bedingungen. Dazu zählen, dass die Nutzungsbedingungen des KI-Werkzeugs rechtlich kompatibel zu Debian sind, die Klärung von Lizenz und Attribution von Fremdcode, den die KI erzeugt, die volle Verantwortung der Beitragenden für Qualität und Lizenzkonformität sowie eine Offenlegungspflicht bei signifikantem KI-Anteil. Dafür schlagen sie Git-Trailer wie Generated-By: oder Assisted-By: vor.
Statt den Gesellschaftsvertrag zu ändern, plädieren sie dafür mit Bezug auf die Debian Verfassung 4.1 (5) [6] eine entsprechende Erklärung zu veröffentlichen. Diese ließe sich bei Bedarf ohne eine erneute Generalresolution anpassen. Die Erklärung soll nicht nur die sechs Bedingungen festhalten, sondern sowohl anerkennen, dass KI-unterstützte Beiträge viele Bedenken aufwerfen, aber auch viele Beitragende KI-Werkzeuge bei der Arbeit an Debian hilfreich fänden.
Ein weiterer Vorschlag lehnt LLMs und generative KI ab, „solange es praktisch ist“. Verfasser Ian Jackson begründet das mit einer ganzen Reihe von Kritikpunkten: Untergrabung von Community-Mechanismen, Umweltschäden, Ausbeutung von Autorinnen und Autoren, aggressives Scraping und die Verbreitung von Fehlinformationen. Da aber die Breite der Software-Welt einer anderen Ansicht sei, inklusive Upstream-Projekte, die Debian nutze, sei eine komplette Ablehnung unpraktisch.
Der Vorschlag fordert, LLM-Nutzung so weit wie möglich zu vermeiden und ruft Projektverantwortliche aber auch die Open-Source-Community auf, von der Nutzung abzuraten. Die Regeln zu KI-Nutzung wollen die Verfasser verbindlich im Code of Conduct festhalten und diesen entsprechend ergänzen. Kernpunkt: Nachrichten an Menschen – also Bugreports, Mailinglisten-Beiträge, Salsa-Diskussionen und Planet-Debian-Blogposts – müssen vollständig ohne LLM-Hilfe verfasst werden. Jede KI-Nutzung bei Debian-Arbeit ist offenzulegen, einzelne Teams dürfen LLM-Beiträge komplett verbieten, und Verstöße werden als Verletzungen des Code of Conduct behandelt. Am Projekt Mitwirkende, die sich des Englischen nicht sicher genug fühlen, sollen in ihrer Muttersprache schreiben und davon ausgehen dürfen, dass Rezipienten ein „Übersetzungstool ihrer Wahl“ einsetzen. Das geht praktisch nur mit einem KI-Tool.
Der letzte Vorschlag wählt ebenfalls einen pragmatischen Ansatz: Debian empfehle generative KI zwar nicht, erkenne aber an, dass die Praktiken bereits verbreitet seien und nicht wieder verschwinden. Die Nutzung zu verbannen sei kontraproduktiv und nicht durchsetzbar. Stattdessen sollen Richtlinien für Debian-spezifische Arbeiten – Websites, Anwendungen, Ressourcen, Pakete – gelten; Upstream ist auch hier explizit ausgenommen. Der Vorschlag akzeptiert KI-Beiträge, sofern sie DFSG-konform sind und als solche ausgewiesen sind. Die Beitragenden tragen die alleinige Verantwortung, müssen den KI-Output verstehen und verteidigen können. Alle Inhalte müssen selbständig auf die Debian-Infrastruktur hochgeladen werden. Die Nutzung von cloudbasierten KI-Diensten für sensible Inhalte soll zudem untersagt sein.
Die Diskussionsphase zur Generalresolution begann am 24. Juli 2026. Die Debian-Entwickler haben jetzt mindestens zwei Wochen Zeit zur Diskussion. Danach folgt dann die Abstimmungsphase, in der alle aktuellen Debian-Entwickler einen Wahlzettel erhalten und diesen signiert per E-Mail zurückschicken. Da Debian Wahlen als Präferenzwahl durchführt, müssen die Wahlberechtigten sich nicht für eine Option entscheiden, sondern können eine Rangfolge bestimmen.
Nicht nur bei Debian sind LLM und generative KI umstritten, auch in vielen anderen Open-Source-Projekten gibt es Diskussionen. Andere Projekte wie Gentoo, Gnome und Codeberg haben bereits eigene KI-Regelwerke etabliert. Auch FreeBSD hat LLM-generierten Quellcode klar abgelehnt [7] – mit Lizenzbedenken als primärem Argument. Für die einen ist es ein Tool, das auch Chancen bietet [8], etwa bei Übersetzungen, verbesserter Usability oder dem Einstieg ins Programmieren. So plant etwa Fedora einen KI-optimierten Linux-Desktop [9], der lokale KI-Stacks für Entwickler zugänglicher machen soll. Andere sehen praktische Bedenken, wie Qualität und Wissensverlust, aber auch die Last, die KI gerade bei Open-Source-Projekten verursacht [10]: AI Slop, unbrauchbare Bugreports und KI-Scraping-Tools, die die Projektserver abgrasen und dabei in die Knie zwingen. Daneben gibt es auch grundsätzliche ethische Bedenken. Auch bleibt die Frage, ob selbst eine Open-Source-KI die Unabhängigkeit einschränke, weil in der Regel die Ressourcen für die immensen Trainingsdaten nicht leistbar sind.
URL dieses Artikels:
https://www.heise.de/-11378236
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Natalia Klenova / Shutterstock.com)
Kleine, aber interessante Meldungshäppchen vom News-Buffet zu GitLab, Kotlin, Unity, WebAuthn, Nuxt, Angular, distr, Apache Arrow, VS Code und GitHub.
In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:
unity command eval (C#-Code im Editor oder Player ausführen) können KI‑Agenten Unity‑Projekte damit beobachten, verändern und die Ergebnisse prüfen.hypot auch eine neue Compute-Funktion. Sie berechnet die euklidische Norm stabil und vermeidet dabei Überläufe, die bei einer naiven Implementierung auftreten würden. Insgesamt umfasst das Update 225 gelöste Issues und 268 Commits von 66 Mitwirkenden.Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail [15].
URL dieses Artikels:
https://www.heise.de/-11372973
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: iX)
Um KI erfolgreich in Code-Audits einzusetzen, ist die Wahl des Modells gar nicht so wichtig. Entscheidend ist der Workflow, damit man nicht in Funden versinkt.
KI als Spürhund für bessere Pentests und Codereviews einzusetzen, klingt im ersten Moment naheliegend. Aber ein Selbstläufer ist das nicht. Das zeigen die vielen Klagen der Open-Source-Projekte, die vor einer Flut von KI-Meldungen vermeintlicher Lücken stehen. Wie man seinen Workflow dafür anpassen muss, warum Mozilla das vorbildlich wuppt und wo jetzt der Flaschenhals liegt – das erklärt Stephan Zeisberg, Titelautor der neuen iX 8/2026.
(Bild: iX)
Wenn KI so viele Lücken aufspürt, müsste die Softwarewelt damit doch sicherer werden. Warum geraten stattdessen viele Open-Source-Projekte und Security-Teams gerade jetzt unter Druck?
Weil das reine Erzeugen einer Schwachstellen-Meldung inzwischen die billigste Stufe im Prozess geworden ist. Der eigentliche Wert entsteht aber erst weiter oben. Ein Befund wird erst dann zu Sicherheit, wenn ein Mensch prüft, ob er echt ist, ob er im konkreten System erreichbar ist und ob ein Patch das Problem wirklich löst. Genau dort sitzt jetzt der Engpass. curl hat sein Bug-Bounty-Programm im Januar eingestellt, HackerOne den Internet Bug Bounty im März pausiert, Node.js sein eigenes Bounty kurz danach suspendiert, und Linus Torvalds nennt die Linux-Kernel-Security-Liste im Mai öffentlich „almost entirely unmanageable“.
Alle geben denselben Grund an: KI-Werkzeuge produzieren plausibel klingende Reports schneller, als die Empfängerseite sie triagieren, verifizieren und beheben kann. Der Anteil echter Schwachstellen in diesen Reports ist niedrig geblieben, was massiv gestiegen ist, ist das Volumen. Wer nur mehr Findings zählt, misst nicht mehr Sicherheit, sondern die Belastung des Systems. Sicherer wird die Welt erst, wenn die Verifikationsseite mit der Discovery-Seite mitwächst, und das tut sie gerade nicht.
Was ist denn wichtiger für den Erfolg KI-gestützter Audits – ein möglichst starkes Modell oder doch eher der Workflow?
Beides zählt, aber der Hebel liegt eindeutig im Workflow, vor allem für Teams, die KI-Audits gerade erst einführen. Ein zusätzlicher Punkt auf einem Coding-Benchmark bringt weniger als eine ordentliche Reproduktions-Stufe im Prozess. Das zeigt Mozilla mit Firefox 150: 271 geschlossene Sicherheitsbugs in einem einzigen Release, darunter ein 20 Jahre alter Fehler in der XSLT-Engine, kamen nicht aus einem neuen Modell allein. Sie kamen aus einer Pipeline, in der jedes Modell-Finding einen reproduzierbaren Testfall mitbringen muss. Das Modell liefert Kandidaten, die Pipeline sortiert das Rauschen aus.
Mozilla hat seit Jahren eine Fuzzing-Infrastruktur mit reproduzierbaren Test-Cases, automatisierter Deduplizierung und integriertem Triage-Prozess aufgebaut. Darauf haben sie die agentische Test-Pipeline gesetzt, die das KI-Modell zwingt, jeden Befund mit einem reproduzierbaren Testfall zu belegen und die Reproduktion selbst zu fahren. Was sich nicht reproduzieren lässt, fällt raus, bevor ein Mensch es sieht. Der Punkt, der leicht übersehen wird: Neu ist nicht der Baustein, sondern die Kombination.
Umgekehrt gilt: Das stärkste Modell ohne diese Disziplin produziert mehr Rauschen, nicht mehr Sicherheit. Die 80 Prozent Falsch-Positive, die für 2024 und 2025 vielfach berichtet wurden, galten für Modelle, die ohne Reproduktions-Stufe direkt auf eine Codebasis angesetzt wurden. Mit einer disziplinierten Pipeline fällt der Wert deutlich. Welches Modell darauf läuft, ist am Ende zweitrangig gegenüber der Frage, ob überhaupt eine Pipeline da ist.
Und was sollte ein Team tun, das mit KI-Codeaudits starten will, aber nicht die ausgefeilte Infrastruktur Mozillas zur Verfügung hat?
Vor allem: nicht früh und breit einsetzen. Genau das produziert die Triage-Tretmühle, in der Reviewer nur noch Tool-Output aussortieren, statt selbst zu lesen. Was in der Praxis funktioniert, ist ein disziplinierter Einsatz in drei getrennten Stufen. KI vor dem Audit, um die Codebasis zu kartieren, Module und Eintrittspunkte zu identifizieren. KI während des Audits als Navigations- und Recherche-Hilfe. Und KI nach dem manuellen Review als zweite Sicht, die bekannte Muster prüft. Die Reihenfolge ist entscheidend: Wenn KI die erste Sicht liefert, prägt sie den Ersteindruck der Reviewer. Wenn sie die letzte Sicht ist, findet sie, was Menschen entgangen ist.
Dazu vier Regeln: Jedes KI-Finding braucht einen falsifizierbaren Reproduktionsfall, sonst bleibt es Hypothese. Die Findings-Menge wird pro Code-Bereich gedeckelt, damit die KI ihre Kandidaten selbst priorisiert; sonst lernen Reviewer, den ganzen Kanal zu ignorieren. Threat-Modell und die Einschätzung des Schweregrads bleiben in menschlicher Hand. Und wo KI auch Code schreibt, greift eine zusätzliche Schwelle mit dokumentierter Absicht und Negativ-Testfällen. Für Solo-Maintainer, die kritische Open-Source-Bibliotheken alleine tragen, ist das übrigens kein realistisches Programm. Dort ist die Antwort weniger ein besserer Workflow als eine gemeinschaftlich finanzierte Triage-Kapazität.
Stephan, vielen Dank für die Antworten! Einen Überblick, wie sich KI sinnvoll in Codereviews nutzen lässt, [1] gibt es in der neuen iX. Außerdem zeigen wir, wie KI-Tools im Unternehmensumfeld für Pentesting [2] genutzt werden. All das und viele weitere Themen finden Leser im August-Heft, das ab sofort im heise Shop [3] oder am Kiosk erhältlich ist.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne [4] oder hinterlassen Sie einen Kommentar im Forum.
URL dieses Artikels:
https://www.heise.de/-11377461
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Buchstaben AI umfliegen Haken und Warndreiecke.
(Bild: tadamichi/Shutterstock.com)
Ein IT-Forscher hat mit der chinesischen KI Kimi K3 mehrere Zero-Day-Lücken in der redis-Datenbank entdeckt. Updates bestätigen die Funde.
Die Entwickler der quelloffenen In-Memory-Datenbank redis haben aktualisierte Versionen veröffentlicht, die mehrere Schwachstellen darin schließen. Sie bestätigen damit Sicherheitslücken, die ein IT-Forscher mit der chinesischen KI Kimi K3 gefunden hat. Die steht in Konkurrenz zu den aktuellen Spitzenmodellen von OpenAI und Anthropic [1] und beweist damit nun, dass sie tatsächlich Schwachstellen aufspüren kann.
Der User „Chaofan Shou“ hat auf X [2] gepostet, dass er mit der KI des chinesischen Start-ups Moonshot AI in 90 Minuten insgesamt 19 Zero-Day-Schwachstellen in der bis dahin aktuellen Fassung 8.8.0 der redis-Datenbank gefunden hat. Kimi K3 hat dabei auch Proof-of-Concept-Code (PoC) erstellt, um das Ausnutzen der Lücken zu demonstrieren. Shou hat ein GitHub-Repository mit den PoCs [3] veröffentlicht.
In der Nacht zum Freitag hat das redis-Projekt nun mehrere aktualisierte Versionen veröffentlicht, die zumindest Teile der vorgestellten Sicherheitslecks stopfen. redis 8.8.1, 8.6.5, 8.4.5, 8.2.8, 7.4.10, 7.2.15 und 6.2.23 [4] bessern mehrere der Schwachstellen aus. Die Entwickler bestätigen damit die Sicherheitslücken, im Beispiel etwa für den Exploit „P88W“ [5] aus dem Schwachstellenrepository.
Eine Einordnung des Schweregrads der Lücken sowie etwa CVE-Schwachstelleneinträge fehlen derzeit noch. Allerdings macht es der verfügbare Proof-of-Concept-Code Angreifern leichter, die Sicherheitslecks zu missbrauchen. IT-Verantwortliche sollten daher zügig auf die aktualisierte redis-Version ihres eingesetzten Entwicklungszweigs updaten. Quellcode steht bereit, die Linux-Distributionen dürften kurzfristig ebenfalls Aktualisierungen in der Softwareverwaltung bereitstellen.
Die Kimi-K3-KI von Moonshot AI erfährt eine große Nachfrage. Der Anbieter hat neue Abonnements aufgrund von GPU-Engpässen vorerst gestoppt. Der Beleg, dass Kimi K3 Schwachstellen aufspürt und Exploit-Code erzeugt, dürfte das Interesse daran weiter wachsen lassen. Das war bislang Domäne etwa von Anthropics Mythos oder Fable [6] oder OpenAIs Codex Security [7].
URL dieses Artikels:
https://www.heise.de/-11377360
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Claude und iPhone: Ein Paradies für Vibecoder?
(Bild: gguy/Shutterstock.com)
Im App Store landen immer mehr Apps, die per Prompt entwickelt wurden. Claude Code macht es Interessierten noch ein bisschen einfacher.
Anthropic hat die macOS-Version von Claude Code aufgerüstet: Entwickler von iOS-Apps bekommen nun die Möglichkeit, das Ergebnis ihrer Prompt-Arbeiten direkt in einem Simulator-Fenster einzusehen, wie man es sonst von Xcode kennt. Aktuell wird die Integration noch als Beta tituliert, ist aber bereits clever umgesetzt: Computer Use [1], also die Erlaubnis für Claude zur direkten Steuerung des Mac, ist dafür nicht notwendig.
Technisch bedient sich Claude Code für macOS [2] beim in Xcode integrierten iOS-Simulator. Entsprechend muss Apples Entwicklungsumgebung [3] installiert sein, was bei den meisten Developern standardmäßig der Fall sein dürfte. Mit aktivem Simulator kann Claude Apps, die es laufen lässt, sehen und mit ihnen interagieren [4] – sowie die Prompt-Schritte weiter iterieren, bis das Ergebnis stimmt. Der Nutzer kann den iOS-Simulator jederzeit auch selbst nutzen, um auszuprobieren, wie sich eine App aktuell anfühlt.
Wer Claude Code per Kommandozeile im Terminal (Claude Code CLI) nutzt, ist allerdings weiterhin auf Computer Use angewiesen. Dabei bedient der Programmieragent die Maus. Sollte Xcode nach Installation keine aktiven Simulatoren anzeigen, muss zuerst die notwendige Runtime heruntergeladen werden [5] – das geht entweder in den Xcode-Einstellungen oder über das Kommando xcodebuild -downloadPlatform iOS im Terminal.
Der direkt in Claude Code integrierte Simulator dürfte die Erstellung von iOS-Apps per Vibe-Coding noch einfacher machen, als dies bislang schon möglich ist. Apples App Store wird seit der Verbreitung von Coding-Agenten wie Claude Code, OpenAI Codex oder Gemini Code Assist mit immer mehr neuen Apps konfrontiert [6], deren Qualität manchmal zu wünschen übrig lässt, da nun auch Nutzer mit wenig bis gar keiner Programmiererfahrung leicht eigene Anwendungen entwickeln können. Apple selbst integriert Vibe-Coding-Werkzeuge auch schon direkt in Xcode [7].
Erste Hinweise zur Verwendung des iOS-Simulators in Claude Code für macOS beschreibt Anthropic in einem neuen Supportdokument [8]. Achten sollte man unter anderem darauf, dass Claude Code den Simulator zwischenzeitlich automatisch herunterfährt und die Zahl der Sessions beschränkt. Auch muss man die notwendigen Permissions beachten, damit der Coding-Agent mit dem virtuellen iPhone agieren kann.
URL dieses Artikels:
https://www.heise.de/-11375592
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Wolf Hosbach/iX/KI)
Die neue, auf Racket basierende Sprache Rhombus erlaubt mächtige, flexible und saubere Makroprogrammierung bei einfach zu lesender Syntax.
Traditionell müssen sich Programmierer beim Thema Makroprogrammierung zwischen zwei Extremen entscheiden: einem mächtigen Makrosystem oder einer leicht lesbaren Syntax. Die neue Sprache Rhombus, am 22. Juni 2026 in Version 1.0 erschienen, will beides gleichermaßen: einen einsteigerfreundlichen Blick auf einen alten Makro-Syntax-Streit und eine moderne Antwort darauf.
Rhombus [1] ist stabil und basiert auf der ausgereiften Racket-Plattform, ist als Sprache aber noch jung und hat ein kleines Ökosystem. Also eher etwas zum Erkunden als eine naheliegende Wahl für das nächste Produktionsprojekt.
Hinter Rhombus steht das Team von Racket [2], einer etablierten Sprache aus der Lisp-Familie [3], seit Jahrzehnten in Forschung und Lehre verbreitet und für ihr besonders mächtiges Makrosystem bekannt. Das Team hat Rhombus erstmals 2023 auf der angesehenen OOPSLA-Konferenz für Programmiersprachen [4] vorgestellt.
Kurz gefasst ist Rhombus eine universelle, dynamische Sprache [5] mit funktionalem Kern. Daten sind standardmäßig unveränderlich, Funktionen und Ausdrücke stehen im Mittelpunkt und Pattern Matching (das Verzweigen anhand der Struktur von Daten) zieht sich durch die ganze Sprache. Dynamisch heißt dabei, dass Typen grundsätzlich zur Laufzeit geprüft werden, wie in Python oder Ruby. Zusätzlich bringt Rhombus ein vollwertiges Klassensystem für objektorientiertes Arbeiten und optionale, geprüfte Typangaben mit. Ob Entwicklerinnen und Entwickler funktional, objektorientiert oder gemischt arbeiten wollen, bleibt ihnen überlassen.
Konzeptionell ruht Rhombus auf drei technischen Schichten.
: öffnet einen Block, ein senkrechter Strich | markiert Alternativen, und die Einrückung gruppiert zusammengehörigen Code. Diese Schicht ist bewusst generisch und wiederverwendbar gehalten.Die Besonderheit: Vieles, was in anderen Sprachen fest in den Compiler eingebaut ist, ist in Rhombus eine Bibliothek: Pattern Matching, Klassen, typ-artige Annotationen und neue Kontrollstrukturen. Dieses Konzept ist dann für die einfach zu handhabende Markoprogrammierung entscheidend.
Technisch steht Rhombus auf solider Grundlage: Es läuft eben auf der Racket-Plattform, kompiliert über Chez Scheme (eine besonders schnelle Scheme-Implementierung) zu nativem Maschinencode und nutzt die etablierten Racket-Werkzeuge. Dabei ist es quelloffen und kostenlos, wahlweise unter der MIT- oder der Apache-2.0-Lizenz. Dateien tragen die Endung .rhm und beginnen mit der Zeile #lang rhombus (analog zu #lang racket).
Rhombus verhält sich also zu Racket wie Kotlin zu Java oder Elixir zu Erlang. Eine modernere Sprache auf bewährter Laufzeitumgebung.
Wer schon einmal programmiert hat, erkennt das meiste sofort wieder. So sieht zum Beispiel Hallo-Welt in Rhombus aus:
#lang rhombus
println("Hallo, Bob!")
Die erste Zeile #lang rhombus legt fest, in welcher Sprache die Datei geschrieben ist, danach folgt direkt der Code. Auch eine kleine Funktion bleibt übersichtlich:
#lang rhombus
fun gruesse(wen):
"Hallo, " +& wen +& "!"
println(gruesse("Bob"))
Eine Funktion beginnt mit fun, der Doppelpunkt öffnet ihren Rumpf, die Einrückung füllt ihn (+& verbindet dabei zwei Texte). Heraus kommt „Hallo, Bob!“. Alles wirkt wie eine ganz gewöhnliche, moderne Sprache, ungefähr im Stil von Python oder Swift.
Werte definiert man mit def. Beim Rechnen lohnt ein genauer Blick: +& verbindet Text, + rechnet mit Zahlen.
#lang rhombus
def name = "Welt"
def jahr = 2026
println("Hallo, " +& name +& "!")
println(jahr + 1)
Ausgabe (als Kommentar):
// Hallo, Welt!
// 2027
Eine Funktion, wie oben im Beispiel gruesse, gibt automatisch ihren letzten Ausdruck zurück, ein return ist nicht nötig. Neu ist hier die ::-Schreibweise: Sie hängt an einen Parameter eine geprüfte Annotation, also eine Art Typangabe. a :: Int bedeutet, dass a eine ganze Zahl sein muss, und :: Int hinter der Parameterliste sagt dasselbe über den Rückgabewert. Passend zum dynamischen Charakter prüft Rhombus solche Annotationen zur Laufzeit; ein statisches Typsystem ist es also nicht.
#lang rhombus
fun addiere(a :: Int, b :: Int) :: Int:
a + b
println(addiere(20, 22))
Ausgabe: // 42
Listen schreibt man in eckigen Klammern. Die for-Form kann zweierlei: eine neue Liste aufbauen (eine Comprehension) oder mit einem Akkumulator einen Wert aufsummieren. Ein Akkumulator ist dabei eine Sammelvariable, die in jedem Durchlauf einen neuen Wert erhält und so das Zwischenergebnis über die Durchläufe hinweg fortschreibt:
#lang rhombus
def zahlen = [1, 2, 3, 4, 5]
def quadrate = for List (z: zahlen):
z * z
println(quadrate)
def summe = for values(akku = 0) (z: zahlen):
akku + z
println(summe)
Ausgabe:
// [1, 4, 9, 16, 25]
// 15
Apropos Zahlen: Rhombus rechnet exakt. (3 + 4) / 2 ergibt nicht die Gleitkommazahl 3.5, sondern denselben Wert als exakten Bruch 7/2.
Pattern Matching, also das Verzweigen anhand der Struktur von Daten, durchzieht die ganze Sprache. Mit match prüft man der Reihe nach mehrere Muster, jeweils hinter einem |. Das erste passende Muster gewinnt. Beachten Sie das dritte Muster [x, y]: Es trifft nur auf Listen mit genau zwei Elementen zu und zerlegt sie gleich in x und y.
#lang rhombus
fun beschreibe(ding):
match ding
| 0: "die Null"
| n :: Int: "die Zahl " +& n
| [x, y]: "ein Paar: " +& x +& " und " +& y
| other: "etwas anderes"
println(beschreibe(0))
println(beschreibe(42))
println(beschreibe([3, 4]))
println(beschreibe("hallo"))
Ausgabe:
// die Null
// die Zahl 42
// ein Paar: 3 und 4
// etwas anderes
Schön zu sehen: Die Muster mischen konkrete Werte (0), Annotationen (n :: Int) und Strukturen ([x, y]) in einer einheitlichen Schreibweise.
Auch ein einheitliches Klassensystem gehört dazu. Eine Klasse definiert man kurz und bündig, und dasselbe Muster, mit dem man Objekte erzeugt, lässt sich auch zum Zerlegen verwenden:
#lang rhombus
class Rechteck(breite, hoehe)
fun flaeche(r :: Rechteck):
r.breite * r.hoehe
def r = Rechteck(10, 5)
println(r)
println(flaeche(r))
def Rechteck(b, h) = r
println("Breite: " +& b +& ", Hoehe: " +& h)
Ausgabe:
// Rechteck(10, 5)
// 50
// Breite: 10, Hoehe: 5
Die vorletzte Zeile ist bemerkenswert: def Rechteck(b, h) = r benutzt den Klassennamen nicht zum Erzeugen, sondern zum Auseinandernehmen eines Rechtecks. Genau dafür sorgen die erwähnten Binding Spaces, in denen Rechteck je nach Position etwas anderes bedeutet.
Ein weiteres Element ist die Ellipse ..., mit der sich Wiederholungen kompakt ausdrücken lassen. Das Muster [x, ...] bindet alle Elemente einer Liste auf einmal, und beim Aufbauen verteilt sich die Rechnung elementweise:
#lang rhombus
def [x, ...] = [1, 2, 3]
def [y, ...] = [10, 20, 30]
println([x + y, ...])
Ausgabe: [11, 22, 33]
Über diese Beispiele hinaus bietet Rhombus generische, unveränderliche funktionale Datenstrukturen mit guter Laufzeitkomplexität (etwa Anhängen in O(log n), also auch bei vielen Elementen schnell) und hierarchische Namensräume. Mitgeliefert sind laut Homepage Bibliotheken für HTML, JSON, XML, HTTP, Zeichnen, GUIs, Parsing und FFI-Bindings (also Anbindungen an fremde, meist C-Bibliotheken).
Bis hierhin sieht Rhombus aus wie eine moderne, aufgeräumte Sprache. Der eigentliche Clou kommt mit den Möglichkeiten der Makroprogrammierung.
Für Entwicklerinnen und Entwickler, die in Sprachen wie PHP, Java oder Ruby zu Hause sind, ist Makro vielleicht nur ein vages Wort. Und falls sie aus der C- oder C++-Welt kommen: Deren #define-Makros sind nur simple Textersetzung und etwas ganz anderes als das, worum es bei Rhombus geht.
In den allermeisten Sprachen steht der Vorrat an Bausteinen fest. Schlüsselwörter wie if, for oder class und Operatoren wie + oder * hat die Sprachdefinition ein für alle Mal festgelegt. Anwender kombinieren diese Bausteine zu Programmen, aber sie können keine neuen erfinden. Wer ein eigenes Schlüsselwort oder einen eigenen Operator verwenden möchte, müsste dafür den Compiler der Sprache selbst umbauen.
Ein Makro durchbricht diese Grenze. Es ist Code, der anderen Code erzeugt oder umschreibt, und zwar zur Compile-Zeit, also bevor das fertige Programm läuft. Anders gesagt: ein kleines Programm, dessen Ausgabe wiederum Programmtext ist. Etwas in dieser Richtung kennen manche von Ruby, wo sich Methoden mit Metaprogrammierung zur Laufzeit erzeugen lassen. Doch Rubys Ansatz hat zwei Grenzen. Erstens passiert das zur Laufzeit. Zweitens erzeugen Entwickler damit nur Methoden und Objekte innerhalb von Rubys fester Syntax. Ein neues Schlüsselwort, einen eigenen Operator oder eine eigene Kontrollstruktur lässt sich so nicht hinzufügen. Die Syntax selbst bleibt unantastbar.
Anders bei Lisp: Lisp ist eine der ältesten Programmiersprachen überhaupt, Ende der 1950er-Jahre entstanden, und Stammvater einer ganzen Sprachfamilie, zu der auch Scheme und Racket gehören. Berühmt, manche sagen berüchtigt, ist sie für zwei Dinge: ihr extrem mächtiges Makrosystem und ihre vielen Klammern.
Lisp-Makros laufen im Unterschied zu Ruby zur Compile-Zeit, bevor ein Programm überhaupt startet. Das Makro formt das Programm schon in dieser Phase um. Der Compiler liest zuallererst den Quelltext und baut daraus einen Syntaxbaum. Das ist eine strukturierte Darstellung des Programms, die festhält, was ein Ausdruck ist und was zusammengehört. Lisp-Makros arbeiten auf diesem Baum und verstehen also die Struktur des Programms. Dadurch können sie echte neue Syntax hinzufügen, eigene Operatoren und Schlüsselwörter eingeschlossen.
Sie sind außerdem hygienisch, verwechseln also nie versehentlich Variablennamen aus Ihrem Code mit anderen, ein Stolperstein, an dem simple Textersetzung gerne scheitert. So lässt sich die Sprache gefahrlos und ohne jeden Compiler-Umbau per Bibliothek erweitern.
Der Preis für diese Macht ist die berüchtigte Klammerflut, die sogenannte S-Expression-Syntax (von „symbolic expressions“, symbolische Ausdrücke). In Lisp wird alles als Liste in Klammern geschrieben, und die Operation steht vorne. Statt 1 + 2 schreibt man (+ 1 2), statt f(x) schreibt man (f x). Das gilt ausnahmslos, auch für das, was anderswo eigene Schlüsselwörter sind. Aus der Bedingung x > 0 wird (> x 0), und sogar ein if ist nur eine Liste: (if Bedingung Dann-Zweig Sonst-Zweig). Weil sich diese Listen ineinander verschachteln, türmen sich die Klammern. „Wenn x größer als 0, dann f(x), sonst g(x)“ sieht so aus: (if (> x 0) (f x) (g x)).
Genau das ermöglicht aber erst die Makro-Macht von Lisp: Es gibt keine Sondersyntax. Ein if sieht aus wie ein Funktionsaufruf, ein Funktionsaufruf wie eine Rechnung, alles ist dieselbe Art verschachtelter Liste. Programm und Datenstruktur sehen nicht nur ähnlich aus, sie sind dasselbe. Ein Makro bekommt den Code einfach als verschachtelte Liste und darf ihn umbauen wie beliebige andere Daten. Klammern und Makro-Macht bedingen einander.
Für die meisten Menschen ist diese Schreibweise schwer zu lesen. Es gab über die Jahre etliche Versuche, eine gewohnte Infix-Syntax (also x > 0 statt (> x 0)) auf Lisp zu setzen, doch fast immer ging dabei die Makro-Macht verloren.
Das Versprechen von Rhombus ist nun: volle Makro-Macht bei normaler Syntax. Das Konzept basiert auf der Struktur der Sprache, dass alle Bausteine (wie Klassen, match, die ::-Annotationen usw.) Bibliotheken sind und nicht in Stein gemeißelte Compiler-Magie. Was Bibliotheken können, können Entwicklerinnen und Entwickler auch.
Ein Beispiel wäre ein eigener Operator: +/+ als Durchschnitt zweier Zahlen. In vielen verbreiteten Sprachen geht das gar nicht, in anderen etwa Swift oder Haskell nur in engen Grenzen. In Rhombus schreibt man ihn selbst:
#lang rhombus
operator (a +/+ b):
~stronger_than: +
(a + b) / 2
println(10 +/+ 20)
println(3 +/+ 4)
println(2 + 10 +/+ 20)
Ausgabe:
// 15
// 7/2
// 17
Hier wird das exakte Rechnen sichtbar: 3 +/+ 4 ergibt 7/2, den exakten Bruch statt einer Gleitkommazahl. Wichtiger noch: +/+ ist ein vollwertiger, selbst erzeugter Infix-Operator. Trifft er auf andere Operatoren, braucht er Vorrangregeln. Die gibt man in Rhombus relativ an, mit ~stronger_than oder ~weaker_than, im Beispiel mit ~stronger_than: +. Genau deshalb rechnet Rhombus 2 + 10 +/+ 20 als 2 + (10 +/+ 20) und gibt 17 aus. Ohne diese Vorrangangabe würde Rhombus die Mischung nicht raten, sondern eine ausdrückliche Klammerung verlangen.
Noch eine Stufe tiefer geht ein echtes Makro, also ein eigenes Schlüsselwort, das zur Compile-Zeit umgeschrieben wird. Hier verwandelt zweimal e schon vor der Ausführung den Ausdruck in e + e:
#lang rhombus
import:
rhombus/meta open
expr.macro 'zweimal $e':
'$e + $e'
println(zweimal 21)Ausgabe: 42.
import: rhombus/meta open holt im Listing die Werkzeuge zum Schreiben von Makros. expr.macro definiert ein neues Schlüsselwort für den Ausdruck. Die einfachen Anführungszeichen '...' umschließen Syntax, nicht Text, und $e ist ein Platzhalter für ein Stück Code. Das Makro sagt: Wo immer zweimal e steht, ersetze es vor dem Lauf durch e + e. Das ist keine Textersetzung, sondern eine Umformung auf der echten Programmstruktur. Und sie ist hygienisch, verwechselt also keine Variablennamen aus Makro und Aufrufstelle.
operator und expr.macro sind keine Sonderfunktionen, sondern derselbe Mechanismus, mit dem auch class, match und for gebaut sind. Sie arbeiten mit denselben Mitteln wie die Sprachautoren. An genau dieser Kombination scheiterten andere Versuche jahrzehntelang.
Am bequemsten startet man für Rhombus mit DrRacket, der etablierten, seit Jahren gepflegten, grafischen und integrierten Entwicklungsumgebung (IDE) des Racket-Projekts. Ursprünglich für die Lehre entworfen, gilt sie als besonders einsteigerfreundlich. DrRacket vereint zwei Bereiche in einem Fenster: Oben schreibt man im Editor das Programm, ein Klick auf „Run“ führt es aus. Unten erscheint eine interaktive Konsole (REPL, Read-Eval-Print-Loop), in der man nach dem Lauf einzelne Ausdrücke ausprobieren kann. Dazu kommen Debugger, Syntaxprüfung und eine direkte Anbindung an die Dokumentation.
Rhombus-Dateien öffnet man in DrRacket genau wie Racket-Dateien: Datei mit #lang rhombus am Anfang und der Endung .rhm laden, „Run“ klicken, fertig. Wer lieber im Terminal arbeitet, ruft schlicht racket datei.rhm auf.
Für die Installation gibt es mehrere Wege. Am unkompliziertesten lädt man von der Rhombus-Homepage [6] das fertige Komplettpaket „Combined Rhombus + Racket Install“ herunter, ein Installer-Image, das Rhombus, Racket und die DrRacket-IDE in einem Rutsch einrichtet. Fertige Installer gibt es für Windows, macOS und Linux, jeweils als 64-Bit-Version für Intel/AMD und ARM; für Linux zusätzlich in 32-Bit-Varianten.
Alternativ kann man den Paketmanager brew nutzen:
brew install --cask racket raco pkg install --auto rhombus
Schlanker, aber ohne DrRacket, geht es über die Kommandozeile:
brew install minimal-racket raco pkg install --auto rhombus racket datei.rhm
Das Paket-Ökosystem ist dasselbe wie bei Racket, wobei das Kommandozeilenwerkzeug raco heißt. Ein Programm lässt sich als fertige Anwendung weitergeben. raco exe datei.rhm übersetzt es in eine eigenständige, nativ kompilierte Datei, und raco distribute ordner datei bündelt diese zusammen mit der nötigen Laufzeit in einen Ordner, den man auf andere Rechner mit demselben Betriebssystem kopieren kann. Dort startet das Programm dann ohne installiertes Racket oder Rhombus.
Dabei handelt es jedoch nicht um eine einzelne, statisch gelinkte Datei wie bei Go oder Rust. Die Racket-Laufzeit ist komplett dabei, weshalb schon ein Hallo-Welt-Programm auf einige Megabyte kommt. Ein Build ist plattformgebunden, universelle Binaries für alle Systeme gibt es nicht.
So beeindruckend die Technik ist, ein paar Vorbehalte gehören dazu. Rhombus ist mit Version 1.0 brandneu, und das Ökosystem noch klein. Die realistische, den Einsatz betreffende Frage ist also weniger, was die Sprache kann, als ob sie Verbreitung findet. Das Team selbst gibt sich nicht unkritisch und nennt die Shrubbery-Notation ausdrücklich „nicht perfekt“. Und der vielleicht größte Schatten: Racket selbst hat es trotz jahrzehntelanger technischer Brillanz nie in den Mainstream geschafft. Rhombus erbt diese Eigenschaften mitsamt dem Risiko.
Auf der Habenseite steht dafür echte technische Reife. Version 1.0 verspricht eine Stabilität und Pflege auf dem Niveau, das Racket seit Jahrzehnten bietet. Rhombus ist also kein Wochenend-Experiment, sondern baut auf einer Basis auf, die sich lange bewährt hat.
Ein persönlicher Vorbehalt zum Schluss: Man kann auch ohne Makros glücklich und produktiv programmieren. Die allermeisten Programme dieser Welt sind ohne selbst gebaute Syntax entstanden, und ihre Autoren haben nichts vermisst. Ein mächtiges Werkzeug verführt auch dazu, es überall einzusetzen. Wer einen Hammer in der Hand hält, sieht schnell in jedem Problem einen Nagel, und ein Makro, das sich eine eigene Sprache erfindet, kann ein Projekt ebenso gut in private Dialekte zersplittern, die außer dem Autor niemand mehr flüssig liest. Die eigentliche Kunst liegt deshalb nicht darin, gute Makros zu schreiben, sondern zu wissen, wann man es besser lässt.
URL dieses Artikels:
https://www.heise.de/-11368404
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Treiben die Verhandlungen über die Chatkontrolle auf Seiten der Kommission voran: Vizepräsidentin Henna Virkkunen und Kommissionschefin Ursula von der Leyen.
(Bild: Dati Bendo/EU-Kommission)
Nach ihrem parlamentarischen Coup haben die EU-Länder wie erwartet der erneuten Verlängerung einer Ausnahmeregelung für die Chatkontrolle zugestimmt.
Der EU-Rat hat wie erwartet die erneute Verlängerung einer Ausnahmeregelung für die sogenannte freiwillige Chatkontrolle besiegelt. Das teilte die EU-Kommission am Donnerstag in Brüssel mit. Damit können Anbieter wie Google, Meta oder Microsoft weiterhin auf ihren Plattformen automatisiert nach Abbildungen von Kindesmissbrauch suchen.
Der Rat hat am Donnerstag auch formell zugestimmt, nachdem die Einigung bereits am Mittwoch bekannt geworden [1] war. Mit ihrer Zustimmung nehmen die Länder auch zwei vom EU-Parlament verabschiedete Änderungswünsche [2] an, die die automatischen Scans auf unverschlüsselte Chats beschränken.
Die EU-Kommission, die die treibende Kraft hinter der umstrittenen Chatkontrolle ist, begrüßte die Einigung ausdrücklich, bezeichnete sie aber auch als „Brückenlösung“. Es sei „eine positive Entwicklung“, dass nun die Rechtssicherheit wiederhergestellt sei, nachdem die vorherige Ausnahmeregelung im April ausgelaufen war.
Der Zustimmung war ein bisher beispielloses politisches Ränkespiel vorangegangen. Kommission, Rat und Parlament streiten seit Monaten über eine grundrechtssichere Ausgestaltung der Chatkontrolle. Weil die freiwillige Praxis der Plattformen aber gegen EU-Datenschutzrecht verstößt, benötigten die Unternehmen dafür eine Ausnahmeregelung.
Einer erneuten Verlängerung dieser 2021 eingeführten Ausnahmeregelung hat das Parlament aber mehrfach widersprochen. Damit war das Thema eigentlich vom Tisch. Der Rat hat mit Unterstützung der Fraktion der Europäischen Volkspartei (EVP) und von Parlamentspräsidentin Roberta Metsola dann kurz vor der Sommerpause einen gleichlautenden Gesetzesvorschlag auf die Tagesordnung gedrückt.
Dank eines Verfahrenstricks [3] hätte das Parlament eine absolute Mehrheit benötigt, um den Vorschlag erneut abzulehnen. Die kam in der letzten Sitzung vor der Sommerpause aber nicht zustande. Damit war der Vorschlag des Rates trotz einer einfachen Mehrheit der Gegenstimmen angenommen. Die neue Ausnahme soll bis zum 3. April 2028 gelten.
Bei dem auch „Chatkontrolle 1.0“ genannten Verfahren überprüfen Plattformbetreiber die Kommunikation in ihren Netzwerken auf digitale Muster von bekannten Abbildungen von Kindesmissbrauch. Die Unternehmen sind dazu nicht rechtlich verpflichtet, weshalb von der freiwilligen Chatkontrolle gesprochen wird.
Eine solche Überprüfung von privater Kommunikation verstößt gegen geltendes EU-Recht. Deshalb gab es in der EU seit 2021 eine befristete Ausnahmegenehmigung, die bereits einmal verlängert worden war. Weil das Parlament einer erneuten pauschalen Verlängerung aber nicht zugestimmt hat, lief die Ausnahmeregelung im April aus.
Damit richtet sich der Blick auf die festgefahrenen Verhandlungen über einen dauerhaften Rechtsrahmen. Kommissions-Vizepräsidentin Henna Virkkunen begrüßte die Einigung als „positiven Schritt“ für den Schutz von Kindern. „Aber die EU braucht dauerhafte Regeln“, betonte Virkkunen und forderte Rat und Parlament auf, „eine wirksame, dauerhafte und klare Lösung zum Schutz unserer Kinder zu finden“.
URL dieses Artikels:
https://www.heise.de/-11376651
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Vanessa Bahr / KI / iX)
Codeberg verbietet die Nutzung seiner Daten für KI-Training und plant, KI-generierte Massenprojekte auszuschließen.
Codeberg will den auf der Plattform gehosteten Code und andere Nutzerdaten nicht zum Training großer Sprachmodelle nutzbar machen. Zugleich plant der Berliner Verein, seine Nutzungsbedingungen zu ändern: Repositories, die weitgehend automatisiert durch KI-Agenten entstehen oder mit hohem Ressourcenverbrauch betrieben werden, können künftig gegen die Regeln der Plattform verstoßen. Die Mitgliederversammlung von Codeberg e. V. hat beide Anträge angenommen.
Codeberg [1] ist eine gemeinnützige, gemeinschaftlich betriebene Plattform für freie und quelloffene Software. Sie bietet Git-Hosting auf Basis von Forgejo, außerdem etwa CI/CD, Pages und eine Weblate-Instanz für Übersetzungen. Der Verein mit Sitz in Berlin versteht sich als datensparsame, nichtkommerzielle Alternative zu GitHub und GitLab.
Mit dem ersten Beschluss bekräftigt Codeberg seine bisherige Datenschutzlinie: Weder Quellcode noch Daten von Nutzern und Projekten sollen für generative KI genutzt oder zum Training großer Sprachmodelle (LLMs) herangezogen werden. Das betrifft die Codeberg-Dienste selbst, nicht jedoch zwangsläufig externe Akteure, die öffentlich verfügbare Repositories automatisiert abrufen.
Gerade diese automatisierten Abrufe sieht Codeberg als Problem an: Crawler von KI-Anbietern durchsuchen nicht nur Git-Repositories über den üblichen git clone-Weg. Sie rufen auch zahlreiche Webansichten, Varianten von Issue-Filtern, Historienstände und wiederholt identische Dateien ab. Das belastet die Datenbanken und zwingt die Administratoren zu Limits und Schutzmaßnahmen, die ebenso legitime Nutzer treffen.
Codeberg begründet die Entscheidung zudem mit seiner grundsätzlichen Kritik an LLMs. Der Verein verweist auf steigenden Infrastrukturbedarf, Energieverbrauch und die Belastung kleiner Betreiber durch teurere Hardware. Diese Folgen seien mit dem Anspruch einer ressourcenschonenden, gemeinschaftlich getragenen Infrastruktur schwer vereinbar, argumentiert Codeberg im Blogbeitrag [2].
Der zweite Beschluss zielt auf Projekte, die Codeberg als „vibe-coded“ einstuft. Gemeint sind dabei nicht einzelne KI-gestützte Ergänzungen oder ein Codevorschlag aus einem Sprachmodell. Im Fokus stehen Repositories, deren Inhalt weitgehend durch LLMs oder autonome Agenten entsteht, ohne dass Menschen ihn langfristig prüfen, weiterentwickeln und warten.
Die Mitgliederversammlung nahm den Antrag mit 358 Ja- zu 144 Nein-Stimmen bei 14 Enthaltungen an. Die geplante Änderung der Nutzungsbedingungen soll es Codeberg erlauben, solche Projekte auszuschließen. Der Verein kündigt allerdings keine automatische Suche nach KI-generiertem Code und keine kurzfristige Massenlöschung bestehender Repositories an.
Codeberg nennt Projekte mit aktiver Community oder einer längeren, vor dem LLM-Boom begonnenen Entwicklungsgeschichte als Fälle, die von den neuen Regeln voraussichtlich nicht betroffen sind. Kleine Experimente und Skripte mit geringem Ressourcenverbrauch sollen laut Codeberg in der Praxis in der Regel geduldet werden.
Kritischer sieht Codeberg dagegen Projekte, die KI-Agenten autonom erzeugen, ebenso wie eine stark LLM-gestützte Entwicklung und Repositories mit unverhältnismäßig hohem Speicher- oder CI-Verbrauch. Codeberg beschreibt etwa Projekte, die von einer einzelnen Person betrieben werden, aber große Binärpakete für viele Plattformen bauen und umfangreiche Pipelines ausführen. Der Verein will seine aus Spenden finanzierte Infrastruktur nicht für solche „Geisterprojekte“ vorhalten.
Der Konflikt betrifft nicht nur Codeberg, sondern viele Open-Source-Projekte: KI-Werkzeuge senken die Hürde, Änderungsvorschläge und Pull Requests einzureichen. Das bedeutet jedoch nicht, dass sie den Review-Aufwand senken. Maintainer müssen weiterhin Architektur, Tests, Sicherheit, Lizenzlage und Wartbarkeit prüfen. Bei unpassenden oder oberflächlichen Beiträgen steigt ihre Arbeit sogar.
GitHub hat auf die wachsende Flut solcher Beiträge zuletzt mit Maßnahmen gegen sogenannten KI-Slop [3] reagiert. Gemeint sind massenhaft eingereichte, oft kaum geprüfte Änderungen und Tickets. GitHub setzt damit auf Moderations- und Verwaltungswerkzeuge, anstatt KI-generierte Projekte grundsätzlich aus dem Hosting auszuschließen.
Auf Ebene der Hosting-Infrastruktur setzt Forgejo auf einen weiteren Ansatz [4]: Die Software liefert inzwischen standardmäßig eine restriktive robots.txt aus. Sie soll Crawler, die sich an diese Konvention halten, von problematischen Endpunkten fernhalten. Einen wirksamen Schutz gegen Akteure, die eine robots.txt ignorieren, bietet das allerdings nicht.
Kommerzielle Plattformen regeln die Nutzung von Daten für ihre KI-Funktionen unterschiedlich. GitLab erklärt für Duo [5], Eingaben und Ausgaben außerhalb ausdrücklich freigegebener Datensammlungen nicht aufzubewahren. Nutzungsdaten für Serviceverbesserungen und Fehlersuche sollen demnach nicht zum Training von KI-Modellen dienen. GitHub erlaubt individuellen Copilot-Nutzern dagegen, die Verwendung ihrer Daten für das Modelltraining in den Einstellungen abzuwählen.
URL dieses Artikels:
https://www.heise.de/-11375621
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: software-architektur.tv)
In der englischsprachigen Episode diskutiert Eberhard Wolff mit James Coplien, ob Softwarearchitektur wirklich vor allem das Management von Abhängigkeiten ist?
Ist Softwarearchitektur im Kern nichts weiter als das Verwalten von Abhängigkeiten? Diese verbreitete Annahme stellen der Muster-Pionier James O. „Jim“ Coplien und der Softwarearchitekt Eberhard Wolff in einer englischsprachigen Folge des Videocasts software-architektur.tv [1] mit dem Titel „Software Architecture: What Is It Really About?“ auf den Prüfstand. Wolff selbst hatte das Thema bereits in einer früheren Episode [2] des Videocasts behandelt und die Frage gestellt, ob Abhängigkeiten tatsächlich so zentral für Softwarearchitektur sind, wie die verbreitete Gleichsetzung nahelegt.
Die Debatte trifft einen wunden Punkt der Praxis. In vielen Projekten wird Softwarearchitektur vor allem über Layer-Diagramme, Dependency-Graphen und den Schnitt von Modulen oder Microservices diskutiert. Wie Wolff in der Ankündigung zu dem Gespräch formuliert, werde Architektur teils sogar auf kaum mehr als das Management von Abhängigkeiten reduziert. Genau diese Sichtweise fordert Coplien heraus.
James Coplien [3] ist in der Softwareentwicklung kein Unbekannter. Er gehört zu den Gründungsmitgliedern der Hillside Group, die die Muster-Bewegung im Softwarebereich anstieß, und hat mehrere Konferenzen der Reihe Pattern Languages of Programs (PLoP) mitbegründet. 1996 war er Program Chair der OOPSLA. Seine Arbeiten zu C++-Idiomen zählen zu den drei Hauptquellen des einflussreichen „Design Patterns“-Buchs der Gang of Four, und er prägte das Curiously Recurring Template Pattern (CRTP). Auch die agilen Methoden Extreme Programming und die täglichen Scrum-Standups gehen auf seine Organizational Patterns zurück.
Zusammen mit Trygve Reenskaug, dem Schöpfer von Model-View-Controller, entwarf Coplien das Paradigma DCI (Data, Context, Interaction). Es trennt bewusst zwischen dem, „was ein System ist“ – also dem Domänenmodell und den Daten – und dem, „was ein System tut“, den Anwendungsfällen und Interaktionen. Diese Unterscheidung bildet die Grundlage seiner Kritik am reinen Struktur- und Abhängigkeitsdenken.
Die Ausstrahlung findet am Freitag, 24. Juli 2026, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite [5] einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt [6], der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer [7] (Socreatory) und Ralf D. Müller [8] (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.
URL dieses Artikels:
https://www.heise.de/-11373655
Links in diesem Artikel:
Copyright © 2026 Heise Medien
