Anmelden
(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:
FreshRSS 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
(Bild: Anggalih Prasetya / Shutterstock.com)
Das Agent Framework bringt nun ein vorgefertigtes Harness mit, um aus großen Sprachmodellen Agenten zu machen.
Microsoft hat sein Agent Framework mit einem stabilen, „batteries-included“ Harness ausgestattet. Dieses soll sowohl in Python als auch in .NET große Sprachmodelle in Agenten verwandeln. Bei Microsoft Agent Framework handelt es sich um ein quelloffenes Framework für das Erstellen, Orchestrieren und Deployen von KI-Agenten und Multi-Agent-Workflows.
Wie der Hersteller ausführt, kann ein LLM für sich genommen lediglich Text generieren. Erst durch ein Agent Harness [1] – eine um das Modell herum laufende Runtime – kann es beispielsweise Tools aufrufen, mehrschrittige Aufgaben ausführen oder einen Job bis zur Vervollständigung durchführen. Ein solches Harness ist nun direkt im Agent Framework enthalten.
Das Harness soll vollständig anpassbar sein und sich für lange laufende, autonome Arbeiten wie Forschung, Datenanalyse oder generelle Aufgabenautomatisierung eignen. Intern handelt es sich um einen Chat-Client-Agenten (Agent in Python, ChatClientAgent in .NET) mit hinzugefügten Features, die standardmäßig aktiviert sind. Diese lassen sich anpassen oder entfernen.
Zu den Funktionen zählen unter anderem das Speichern der Chathistorie nach jedem Modellaufruf zur Crash-Wiederherstellung und Inspektion während der Ausführung, ein Dateispeicher für dauerhafte Session Notes, Kontextverdichtung (Compaction), To-Do-Provider, Skills, Websuche, Toolbestätigung und integrierte Telemetrie per OpenTelemetry.
Microsoft führt als Anwendungsbeispiele Datenverarbeitungs-, Domain- und Forschungsassistenten an. So könne ein Forschungsassistent ein Thema in Form von To-Dos planen, zwischen Planungs- und Ausführungsmodi wechseln, das Web durchsuchen und den Plan autonom abarbeiten.
Bisher nur als opt-in verfügbar, stellt Microsoft weitere Features für das Harness bereit: das Delegieren von Unteraufgaben an andere Agenten, Dateizugriff, Looping – also das Wiederaufrufen eines Agenten bis zum Erfüllen einer Bedingung – und Shell-Tooling.
Weitere Informationen zum Microsoft Agent Framework Harness sind im Blogeintrag [4] zur Ankündigung sowie auf Microsoft Learn [5] zu finden. Codebeispiele für .NET [6] und für Python [7] stehen auf GitHub bereit.
URL dieses Artikels:
https://www.heise.de/-11375090
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Matthias Parbel / KI / iX)
BellSofts gehärteter Builder für Paketo Buildpacks baut Container-Images auf einer weitgehend CVE-freien Alpaquita-Basis – ganz ohne Dockerfile.
BellSoft hat einen gehärteten Builder für Paketo Buildpacks vorgelegt. Er soll Entwicklerteams eine weitgehend CVE-freie Basis für Container-Images liefern, ohne dass diese eigene Dockerfiles pflegen müssen. Der Builder richtet sich an Enterprise-Teams, die Sicherheits- und Compliance-Anforderungen erfüllen wollen, ohne den Entwicklungsprozess auszubremsen.
Wie BellSoft in seinem Blog [1] mitteilt, baut der neue Builder vollständig auf BellSoft Hardened Images und damit auf Alpaquita auf, dem hauseigenen schlanken Linux-Betriebssystem, das mit gehärteter Standardkonfiguration kommt. Dazu zählen unter anderem der Non-Root-Betrieb, eine reduzierte Paketbasis und unveränderliche Komponenten. Jede mit dem Builder erzeugte Anwendung erbt laut BellSoft automatisch diese Security- und Compliance-Eigenschaften.
Mit Paketo Buildpacks, einem Projekt der Cloud Native Computing Foundation (CNCF), lässt sich aus Quellcode automatisiert produktionsfertige OCI-Images erzeugen, ohne dabei ein Dockerfile erstellen zu müssen. Ein Buildpack erkennt Sprache und Abhängigkeiten, kompiliert bei Bedarf und produziert ein minimales, reproduzierbares Image samt Software Bill of Materials (SBOM) in einem Schritt. BellSofts Builder kapselt dabei die Buildpacks, den Build-Stack und den Run-Stack. Beide Stacks ersetzt der Hersteller durch seine Alpaquita-basierten Hardened Images, sodass neue Container automatisch auf dem gehärteten OS laufen.
Vor allem Unternehmen, die eine große Anzahl von Services unterhalten, sollen von reduziertem Wartungsaufwand profitieren. Statt Hunderte individuelle Dockerfiles zu pflegen, greift ein einheitliches Rebuild oder Rebase, sobald die Basis-Images aktualisiert werden.
Der Builder unterstützt Java (Liberica JDK und Liberica JDK Lite), GraalVM Native Image über das Liberica Native Image Kit (Liberica NIK), Python, Go, Node.js und Ruby. Im Blog nennt BellSoft die folgenden konkreten Versionen: Python 3.14, Go 1.26, Node.js 24 sowie Liberica NIK in den Versionen 22 und 23. Für Java stützt sich der Builder auf das für Cloud-Workloads optimierte Liberica JDK Lite und deckt die LTS-Versionen 8, 11, 17 und 25 sowie die jeweils aktuelle JDK-Version ab. Laut Hersteller reduziert Liberica JDK Lite die finale Image-Größe von Java-Containern um mindestens 30 Prozent gegenüber Standard-OpenJDK-Images.
Die Images stehen für die Architekturen x86-64 und ARM64 auf Docker Hub bereit und liegen in zwei Varianten der C-Standardbibliothek vor: musl und glibc. Teams, die bereits den bisherigen BellSoft-Builder nutzen, wechseln laut Hersteller mit einem Rebuild und der Option --pull-policy always automatisch auf den neuen Builder und die aktuellsten Buildpacks. Bei einer Migration von Dockerfiles empfiehlt BellSoft, zunächst mit einem nicht-kritischen Service zu testen.
BellSofts Hardened Images versprechen zum Release-Zeitpunkt niedrige bis keine bekannten CVEs. Der Anbieter bietet darüber hinaus kontinuierliches Patchen, SBOMs, digitale Signaturen und ein SLA-gestütztes Vulnerability-Management. Nach der Offenlegung einer Schwachstelle soll innerhalb von rund 24 Stunden ein gepatchtes Image bereitstehen. Jede veröffentlichte Version wird mit vollständiger SBOM und verifizierbarer Herkunft ausgeliefert, um Audits und regulatorische Anforderungen, etwa durch FedRAMP, DISA STIG, den EU Cyber Resilience Act (CRA) und DORA, zu erleichtern.
URL dieses Artikels:
https://www.heise.de/-11373261
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: mundissima/Shutterstock.com)
Google legt neue Light-Varianten seines LLMs auf. Bei der mächtigeren Pro-Variante spießt es sich weiter.
Google legt drei neue Varianten seines multimodalen großen Sprachmodells (LLM) Gemini auf. Das neue Gemini 3.6 Flash soll nicht nur bessere Inferenzen liefern, sondern dabei etwa ein Sechstel weniger Tokens verbrauchen als Vorgänger Gemini 3.5 Flash. Gleichzeitig werden die Tokens selbst günstiger.
Gemini 3.5 hat aber noch lange nicht ausgedient. Vielmehr erhält es zwei Geschwister: 3.5 Flash-Lite soll geringere Latenzen aufweisen als das im Mai auf der Entwicklerkonferenz Google I/O vorgestellte 3.5 Flash [1]. Google bewirbt Flash-Lite speziell für KI-Agenten.
Was nach wie vor fehlt, ist die genauer arbeitende und für komplexere Aufgaben gedachte Pro-Version des Gemini 3.5. Laut einem Bericht Bloombergs plagen den Datenkonzern Qualitätsprobleme. Laut Insidern komme hinzu, dass der Datenkonzern seine KI in viele eigene Produkte gleichzeitig integriert, die so unterschiedlich sein können wie Google Maps und Youtube. Damit würden viele Google-Projekte mitreden, was die Sache nicht gerade beschleunige.
Google selbst belässt es in seiner Ankündigung vom Dienstag [2] mit der Feststellung, dass es Gemini 3.5 Pro mit Partnern teste, und plane, es allgemein verfügbar zu machen, „sobald es bereit ist”. Lieber möchte Google über die Vorbereitungen des Trainings des kommenden Gemini 4 reden.
IT-Sicherheitsbewegte möchte das US-Unternehmen mit Gemini 3.5 Flash Cyber bei Laune und damit der Stange halten. Flash Cyber ist für Zusammenarbeit mit dem hauseigenen KI-Agenten Codemender konzipiert und, wie der Name vermuten lässt, auf die Prüfung von Software hinsichtlich Sicherheitslücken spezialisiert.
Nutzen dürfen Flash Cyber aber nur staatliche Dienste und einige von Google ausgewählte Einrichtungen. Codemender kann parallel auch andere großen Sprachmodelle einbinden.
URL dieses Artikels:
https://www.heise.de/-11372719
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Wolf Hosbach / iX / KI)
Die neue Assess-Erweiterung von Spec Kit 0.13 sortiert automatisiert Ideen, bevor sie in eine Spec eingehen. Außerdem beseitigt Spec Kit eine Reihe an Bugs.
Die neue Version 0.13 von Spec Kit, GitHubs Werkzeug für Spec-driven Development, enthält eine neue Extension zur Ideenbewertung sowie kleine Korrekturen für mehr Stabilität und weniger Fehler.
Die neue Extension [1] Idea Assessment Pipeline (assess) schaltet einen weiteren, optionalen Schritt vor den bestehenden Spec-driven-Workflow. Hier lassen sich Ideen rollenneutral testen und bewerten [2], bevor sie in eine Spec übergehen. Das erfolgt in fünf Schritten: Rohe Idee erfassen, Evidenz sammeln, das Problem schärfen, ein Konzept entwerfen und schließlich entscheiden: Go, klären oder Kill. Das positive Urteil überführt die Idee in eine Spec: /speckit.specify.
Bugfixes betreffen die Authentifizierung der Azure-DevOps-CLI: Erhielt das Tool eine nicht dekodierbare Antwort, führte das zum stillen Crash, statt ein erwartetes None auszugeben. Gefixt hat das Team auch unklare Fehlermeldungen bei nicht korrekten Bundle-Download-URLs. Spec Kit wirft jetzt einen klar benannten BundlerError aus. Außerdem ersetzt ein PresetValidationError den bisherigen unklareren ValueError bei ungültigen Katalog-URLs.
Als Tool für das Spec-driven Development plant und steuert Spec Kit die Arbeit von Coding-Agenten. Specs dienen dabei als Kern für Planung, Entwicklung, Testing und Doku. Die Specs liegen oft in Markdown vor und dienen als Single Source of Truth. Dabei arbeitet Spec Kit laut Projekt mit 35 Tools zusammen, darunter GitHub Copilot, Gemini oder Codex. Spec-driven Development [3] steigt in der Bedeutung bei Entwicklerinnen und Entwicklern, ein ähnliches Tool ist OpenSpec [4].
URL dieses Artikels:
https://www.heise.de/-11371623
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Wie Personen mit Autismusdiagnose ihre Fähigkeiten gut im Software-Testing einsetzen können, erklären Helmut Pichler und Markus Kalbhenn.
Menschen mit Autismusdiagnose, die im Wartezimmer spontan 48 Rechtschreibfehler in einer Illustrierten zählen, bevor das Gespräch überhaupt beginnt: Darüber sprechen Helmut Pichler und Markus Kalbhenn mit Richard Seidl. Es erklärt besser als jede Theorie, warum genau diese Fähigkeiten im Software-Testing so gut ankommen. Die drei sprechen darüber, wie das Ausbildungsprogramm TestingPRO [1], in dem Menschen aus dem neurodivergenten Spektrum als Softwaretester ausgebildet werden, aufgebaut ist und welche Anpassungen im Training wirklich den Unterschied machen. Sie besprechen auch, was Unternehmen konkret brauchen, damit die Zusammenarbeit funktioniert. Dabei geht es nicht nur um Pausen und ruhige Räume, sondern auch darum, wie klare Aufgabenstellungen und ein fester Tagesrhythmus aus einer unsicheren Situation ein gutes Arbeitsverhältnis machen können.
„Im Software-Testing, im Qualitätsmanagement sind diese Personen von ihrer Kapazität her, von ihren Potenzialen wie ein Ferrari.“ – Markus Kalbhenn
Helmut Pichler [3] ist ein echter „Vollblut‑Tester/-Berater/-Trainer“, der seit Jahren mit unglaublicher Leidenschaft die Softwaretest‑Community prägt und weltweit Standards mitgestaltet. Als Ehren-Präsident vom Austrian Testing Board und langjähriger Botschafter auf internationalen Konferenzen bringt er Menschen zusammen, inspiriert sie und zeigt, wie lebendig Qualitätssicherung sein kann. Mit seinem Know-how als Trainer, Berater und Co-Autor von „Agile Testing“ gilt er im deutschsprachigen Raum längst als eines der Urgesteine und bleibt trotzdem immer am Puls der Zeit. Eines seiner Herzensprojekte, das er federführend mit konzipiert, ist seit nun 10 Jahren TestingPRO.
Markus Kalbhenn [4] ist ein erfahrener Experte im Personalmanagement, der auf 30 Jahre Erfahrung im Recruiting- und Tech-Bereich zurückblickt. In der ETC – Enterprise Training Center GmbH hat er den Bereich Talent Services mit aufgebaut und setzt dort neue Impulse in der IT-Personalvermittlung. Sein Fokus liegt auf der Entwicklung innovativer Recruiting-Methoden, die über konventionelle Ansätze hinausgehen, um dem Fachkräftemangel in der IT-Branche entgegenzuwirken. Besonders hervorzuheben ist sein Engagement für die IT-Ausbildungsprogramme TestingPro und INCLUSIVE-IT, die Menschen mit Behinderungen den Zugang zu IT-Karrieren ermöglichen. Als ausgebildeter Pädagoge und zertifizierter CSR-Berater verbindet er soziale Verantwortung mit wirtschaftlicher Effizienz bei der Besetzung technischer Rollen.
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 [5].
URL dieses Artikels:
https://www.heise.de/-11371595
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Maika Möbus / KI / iX)
So funktionieren Passkeys: Der erste Teil der Praxis-Serie für Entwickler zeigt im Detail die Architektur, die auf FIDO2 und WebAuthn aufbaut.
Passwörter sind nicht deshalb unsicher, weil Menschen nachlässig damit umgehen – sie sind strukturell gebrochen. Das zugrunde liegende Modell beruht auf einem geteilten Geheimnis zwischen Client und Server, das abgefangen, erraten oder durch Datenlecks kompromittiert werden kann. Passkeys setzen an genau dieser Schwachstelle an und lösen das Problem auf architektonischer Ebene: Anstelle eines Passworts kommt ein kryptografisches Schlüsselpaar zum Einsatz. Der private Schlüssel verlässt niemals das Gerät – auf dem Server liegt ausschließlich der öffentliche Schlüssel.
Die Authentifizierung erfolgt lokal, durch Biometrie oder PIN, und ist kryptografisch an exakt eine Relying Party ID gebunden: Ein Credential, das für example.com registriert wurde, kann auf evil-example.com schlicht nicht verwendet werden – egal, ob es auf einem einzelnen Gerät liegt oder via iCloud auf mehreren. Phishing wird damit nicht nur erschwert, sondern technisch unmöglich gemacht.
Der erste Teil dieser Artikelserie steigt direkt auf Architekturebene ein und legt das technische Fundament: Wie greifen FIDO2, WebAuthn und CTAP2 ineinander? Welche Akteure sind an jeder WebAuthn-Interaktion beteiligt, und welche Aufgabe hat jeder von ihnen? Was liefern navigator.credentials.create() und navigator.credentials.get() zurück – und welche Informationen verbergen sich in der authData-Struktur, die beide Methoden durchzieht? Wer diese Fragen beantworten kann, verfügt über das Vokabular und Strukturverständnis, auf dem Registration und Authentication in Teil 2 aufbauen.
Zunächst lohnt sich eine kurze Begriffsklärung – nicht, weil die Begriffe kompliziert wären, sondern weil sie in der Praxis häufig durcheinandergeworfen werden, was zu Verwirrung bei der Implementierung führt.
FIDO2 ist der Oberbegriff. Er kombiniert zwei Spezifikationen, die auf unterschiedlichen Ebenen ansetzen: Web Authentication (WebAuthn) [1] und Client to Authenticator Protocol 2 (CTAP2) [2]. WebAuthn ist die Browser-API, die vom World Wide Web Consortium (W3C) standardisiert wird und die Kommunikation zwischen Webanwendung und Browser beschreibt. CTAP2 ist eine Spezifikation der FIDO Alliance [3] und regelt, wie der Browser beziehungsweise das Betriebssystem mit dem Authenticator kommuniziert. Beide Spezifikationen sind voneinander unabhängig standardisiert, aber konzeptuell aufeinander abgestimmt: WebAuthn definiert, was der Browser nach oben zur Webanwendung durchreicht; CTAP2 definiert, was der Browser nach unten zum Authenticator sendet.
Der Begriff Passkey ist jünger als die beiden Spezifikationen und dient als benutzerfreundliche Bezeichnung für Synced Credentials im Sinne der FIDO Alliance – also Multi-Device FIDO Credentials, die verschlüsselt über ein Cloud-Ökosystem wie iCloud Keychain oder den Google Password Manager auf mehrere Geräte repliziert werden können. Davon abzugrenzen sind Device-bound Passkeys: gerätegebundene Credentials, bei denen der private Schlüssel das Gerät nie verlässt, etwa auf einem Roaming Authenticator wie einem YubiKey. Technisch basieren beide Varianten identisch auf WebAuthn – der Unterschied liegt im Sicherheitsmodell des Authenticators, nicht in der API.
Jede WebAuthn-Interaktion – ob Registration oder Authentication – involviert genau drei Akteure. Ihr Zusammenspiel bestimmt, welche Daten ausgetauscht werden, wer welche Validierungen durchführt und wo das Vertrauen im System verankert ist. Es lohnt sich, diese drei Rollen klar auseinanderzuhalten, denn Verwechslungen führen direkt zu falschen Annahmen in der Serverlogik.
Die Relying Party (RP) ist die Webanwendung, genauer gesagt, der Server dahinter. Sie initiiert beide Ceremonies – Registration und Authentication –, indem sie Options-Objekte mit einer kryptografisch zufälligen Challenge bereitstellt, und validiert anschließend die Antwort des Authenticators. Identifiziert wird sie durch ihre rpId – typischerweise die Domain der Anwendung, etwa example.com. Wichtig dabei: Die rpId muss eine registrierbare Domain-Teilmenge der aktuellen Origin sein. Das bedeutet, dass example.com als rpId für login.example.com gültig ist, aber auth.other.com es nicht für example.com sein darf. Diese Einschränkung klingt technisch, ist aber der eigentliche Kern der Phishing-Resistenz – dazu gleich mehr. Was die RP am Ende einer erfolgreichen Registration speichert, ist ausschließlich der Public Key. Kein Passwort, kein geteiltes Geheimnis.
Zwischen Relying Party und Authenticator sitzt der WebAuthn-Client – in der Regel der Browser, manchmal das Betriebssystem. Er implementiert die navigator.credentials-API und übernimmt die Rolle des Vermittlers: Er empfängt die Options-Objekte der RP, leitet sie an den Authenticator weiter und verpackt dessen Antwort als PublicKeyCredential-Objekt zurück an die Webanwendung. Was dabei oft übersehen wird: Der Client führt eigene Sicherheitsprüfungen durch, bevor er den Authenticator überhaupt kontaktiert. Er validiert, ob die rpId zur aktuellen Origin passt – und bricht die Anfrage mit einem SecurityError ab, wenn das nicht der Fall ist. Das ist keine optionale Validierung, sondern eine Pflichtprüfung des Browsers.
Der Authenticator schließlich ist das Gerät oder die Software, die das Schlüsselpaar erzeugt und Assertions signiert. Konzeptuell ist er eine vollständig separate Vertrauensdomäne – weder Teil der Webanwendung noch des Browsers. Was der Authenticator signiert, haben weder Browser noch RP manipuliert. Genau das macht ihn zur Vertrauensquelle des gesamten Systems.
Das Vertrauensmodell folgt daraus fast zwingend: Der Server vertraut dem registrierten Public Key. Der Browser vertraut dem Authenticator über das CTAP2-Protokoll oder die Plattform-API. Und der Authenticator vertraut der lokalen Nutzerverifizierung – der Biometrie oder der PIN, die den privaten Schlüssel freischaltet. Kein Akteur muss dem anderen blind vertrauen, weil jeder Schritt kryptografisch abgesichert ist.
Es folgt ein genauerer Blick auf den Authenticator – denn nicht jeder Authenticator ist gleich. Die WebAuthn-Spezifikation unterscheidet grundlegend zwischen zwei Varianten, die sich in Sicherheitsmodell, Recovery-Optionen und praktischem Einsatzszenario erheblich unterscheiden. Ein Platform Authenticator ist fest in das Gerät integriert: Touch ID und Face ID auf Apple-Geräten, Windows Hello auf PC und Laptop, Android Biometrics auf Android-Smartphones.
Der private Schlüssel wird direkt im sicheren Element des Geräts erzeugt und gespeichert – in der Secure Enclave auf Apple-Hardware oder dem Trusted Platform Module (TPM) auf Windows-Systemen. Er verlässt diese Sicherheitsdomäne nicht. Bei Synced Passkeys [4] gibt es eine wichtige Nuance: Das Schlüsselmaterial wird verschlüsselt über die iCloud Keychain oder den Google Password Manager auf andere Geräte desselben Ökosystems repliziert. Der Schlüssel selbst bleibt dabei immer geschützt. Was synchronisiert wird, ist ein verschlüsselter Blob, kein Klartext-Schlüssel.
Ein Roaming Authenticator hingegen ist ein externes Gerät, das unabhängig vom Endgerät funktioniert. Die häufigsten Beispiele sind YubiKeys, FIDO2-USB-Sicherheitsschlüssel und NFC-Token. Sie sind per Definition Device-bound – das heißt, sie bleiben fest mit dem Gerät verbunden, auf dem sie erstellt wurden. Ein Cloud-Sync oder Transfer der Schlüssel zwischen Geräten ist nicht möglich. Besonders interessant ist dabei die Rolle des Smartphones als Cross-Device Authenticator: Es kann mittels QR-Code-Scan und einer verschlüsselten Bluetooth-Verbindung (Hybrid Transport) als Roaming Authenticator für andere Geräte dienen – beispielsweise für einen Desktop-Browser, der selbst über keinen Platform Authenticator verfügt.
(Bild: Yubinerd123 [5], CC BY-SA 4.0 [6], via Wikimedia Commons)
Eine verbreitete Fehlannahme ist, dass Synced Passkeys weniger phishingresistent seien als Hardware-Schlüssel. Das stimmt nicht. Phishing-Resistenz ist kein Merkmal eines bestimmten Authenticator-Typs, sondern sie ergibt sich direkt aus dem kryptografischen Origin-Binding der WebAuthn-Spezifikation. Zur Erinnerung: Ein Credential, das für example.com registriert wurde, kann schlicht nicht auf evil-example.com verwendet werden, egal ob es auf einem YubiKey oder in der iCloud liegt. Der Authenticator signiert immer die rpId, die der Browser mitliefert, und der Browser prüft zuvor, ob diese rpId zur aktuellen Origin passt. Der Unterschied liegt woanders: bei der Angriffsfläche des Schlüsselmaterials und bei den Recovery-Optionen. Ausführliche Informationen dazu folgen zu einem späteren Zeitpunkt in dieser Artikelserie.
In den AuthenticatorSelectionCriteria kann die RP über authenticatorAttachment festlegen, welchen Typ sie bevorzugt:
{
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"residentKey": "required",
"userVerification": "required"
}
}Listing 1: authenticatorSelection-Objekt mit Präferenz für Platform Authenticators
"platform" schränkt auf eingebettete Authenticators ein, "cross-platform" auf externe Geräte. "residentKey": "required" erzeugt ein Discoverable Credential – Voraussetzung für eine Anmeldung ohne Benutzernamen.
Bisher wurde hier WebAuthn als die Schnittstelle zwischen Webanwendung und Browser betrachtet. Doch wie kommuniziert der Browser eigentlich mit dem Authenticator? Dafür ist CTAP2 zuständig – und auch wenn Entwicklerinnen und Entwickler mit CTAP2 in der Regel nicht direkt in Berührung kommen, ist es sinnvoll, das Protokoll grob zu verstehen.
CTAP2 definiert das Nachrichtenformat und den Befehlssatz für diese Kommunikation. Nachrichten sind CBOR-kodiert (Concise Binary Object Representation, RFC 8949 [7]). Das binäre Format CBOR ist kompakter als JSON und eignet sich besonders für ressourcenbeschränkte Hardware wie einen USB-Sicherheitsschlüssel. Das Protokoll ist transport-agnostisch: Ein Windows-Browser kann genauso mit einem YubiKey über USB kommunizieren wie ein macOS-Browser mit einem NFC-Token, weil CTAP2 den Transport von der eigentlichen Nachrichtensemantik trennt.
Besonders hilfreich ist die direkte Zuordnung zwischen den CTAP2-Kommandos und den WebAuthn-Ceremonies: authenticatorMakeCredential entspricht der Registration – der Authenticator erzeugt ein neues Schlüsselpaar und gibt den Public Key zurück. authenticatorGetAssertion entspricht der Authentication – der Authenticator signiert eine Challenge mit dem gespeicherten Private Key. Die WebAuthn-API auf Browserebene ruft intern genau diese Kommandos auf. Mit anderen Worten: navigator.credentials.create() ist aus Sicht des Authenticators ein authenticatorMakeCredential, und navigator.credentials.get() ist ein authenticatorGetAssertion. Diese Zuordnung ist das konzeptuelle Bindeglied zwischen der JavaScript-API und dem Low-Level-Protokoll.
| Transport | Beschreibung | Plattformunterstützung |
| USB HID | kabelgebunden, hohe Zuverlässigkeit | Windows, macOS, Linux, Android |
| NFC | kontaktlos, kurze Reichweite | mobile Geräte, NFC-fähige PCs |
| BLE |
Bluetooth Low Energy (drahtlos, energiesparend, mittlere Reichweite) |
Mobile- und Desktop-Plattformen |
| Internal | plattforminterner Kanal (Platform Authenticator) | alle modernen Plattformen |
| Hybrid | QR-Code + BLE-Proximity (früher „caBLE“) | iOS 16+, Android 9+, moderne Desktopbrowser |
Tabelle 1: CTAP2-Transportmechanismen und deren Plattformunterstützung
Besonders erwähnenswert ist der Hybrid Transport, früher unter dem Namen caBLE bekannt. Er ermöglicht es, ein Smartphone als Roaming Authenticator für einen Desktopbrowser zu verwenden, der selbst keinen Platform Authenticator besitzt. Der Ablauf ist einfach: Der Desktop zeigt einen QR-Code an, das Smartphone scannt ihn, und die eigentliche Assertion wird anschließend über eine verschlüsselte Bluetooth-Verbindung übertragen. Aus Entwicklersicht ist dieser Transport vollständig transparent. Er läuft im Client ab und hat keinerlei Einfluss auf die WebAuthn-API oder die serverseitige Validierungslogik.
WebAuthn ist die API, mit der Entwicklerinnen und Entwickler direkt arbeiten. Sie besteht aus den zwei bereits erwähnten Methoden: navigator.credentials.create() für die Registration und navigator.credentials.get() für die Authentication. Beide geben ein PublicKeyCredential-Objekt zurück. Was sich unterscheidet, ist die response-Property darin. Bei der Registration enthält sie eine AuthenticatorAttestationResponse:
// Registration
const credential = await navigator.credentials.create({
publicKey: publicKeyCredentialCreationOptions
}) as PublicKeyCredential;
const attestationResponse =
credential.response as AuthenticatorAttestationResponse;
// attestationResponse.clientDataJSON – ArrayBuffer
// attestationResponse.attestationObject – ArrayBuffer (CBOR-kodiert)
// attestationResponse.getPublicKey() – ArrayBuffer (DER-Format, convenience)Listing 2: create()-Aufruf und Zugriff auf die AuthenticatorAttestationResponse
Bei der Authentication enthält sie eine AuthenticatorAssertionResponse:
// Authentication
const assertion = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
}) as PublicKeyCredential;
const assertionResponse =
assertion.response as AuthenticatorAssertionResponse;
// assertionResponse.clientDataJSON – ArrayBuffer
// assertionResponse.authenticatorData – ArrayBuffer
// assertionResponse.signature – ArrayBuffer
// assertionResponse.userHandle – ArrayBuffer | nullListing 3: get()-Aufruf und Zugriff auf die AuthenticatorAssertionResponse
Beide Responses teilen sich ein gemeinsames Feld: clientDataJSON. Es ist ein ArrayBuffer, der ein JSON-Objekt enthält – erzeugt vom Browser, nicht vom Authenticator. Es enthält type ("webauthn.create" oder "webauthn.get"), challenge als Base64url-String, origin und crossOrigin. Der entscheidende Punkt ist, dass origin und challenge Teil der späteren Signatur werden. Dadurch ist kryptografisch sichergestellt, dass die Antwort weder für eine andere Origin noch als Replay einer früheren Anfrage gültig ist. Das sind zwei Angriffsvektoren, gegen die klassische Passwörter strukturell keine Antwort haben.
Bei der Registration kommt zu clientDataJSON noch das attestationObject hinzu. Es ist CBOR-kodiert und enthält drei Felder: fmt (das Attestation-Format, zum Beispiel "packed", "tpm" oder "none"), attStmt (die formatspezifische Attestation-Aussage) und authData, die zentrale Datenstruktur, auf die der nächste Abschnitt eingeht. Bei der Authentication Response entfällt der Attestation-Wrapper. Dort steht authenticatorData direkt im Response-Objekt, zusammen mit signature und optional userHandle.
Es gibt dabei einige Fehlerszenarien, die in der Praxis regelmäßig auftauchen: Ein NotAllowedError erscheint, wenn der Nutzer die Anfrage abgelehnt hat oder das Timeout abgelaufen ist. Ein SecurityError signalisiert, dass die rpId nicht zur aktuellen Origin passt – ein häufiger Konfigurationsfehler in Entwicklungsumgebungen, wenn man zwischen localhost und einer lokalen Domain wechselt. Und ein AbortError tritt auf, wenn die Anfrage programmatisch über einen AbortController abgebrochen wurde. Das ist relevant, wenn Conditional UI und ein manuell ausgelöster Login-Flow gleichzeitig im Spiel sind und koordiniert werden müssen.
Wer verstehen will, was der Server bei der Validierung tatsächlich prüft, muss die authData kennen. Sie ist die Datenstruktur, die sich durch beide Ceremonies zieht – bei der Registration steckt sie im attestationObject, bei der Authentication erscheint sie direkt als authenticatorData. Ihr Layout ist in §6.1 der W3C-WebAuthn-Level-2-Spezifikation [8] exakt definiert: ein Byte-Array, aufgebaut aus fest definierten Feldern in einer fixen Reihenfolge.
| Offset | Länge | Feld | Beschreibung |
| 0 | 32 Bytes | rpIdHash | SHA-256-Hash der rpId |
| 32 | 1 Byte | flags | Bit-Feld mit Statusinformationen |
| 33 | 4 Bytes | signCount | Big Endian, Zähler für Replay-Schutz |
| 37 | variabel | attestedCredentialData | nur bei Registration, wenn Attested Credential Data Flag gesetzt |
| variabel | variabel | extensions | optional, nur wenn Extension Data Flag gesetzt |
Tabelle 2: Byte-Layout der authData (§6.1 WebAuthn Level 2)
Die ersten 32 Bytes sind der rpIdHash – der SHA-256-Hash der rpId. Das ist das Erste, was der Server prüfen muss: Stimmt dieser Hash mit dem Hash seiner eigenen rpId überein? Sofern er nicht stimmt, wurde die Antwort für eine andere Relying Party erzeugt und muss abgelehnt werden, ohne Ausnahme und ohne Fallback.
Byte 32 enthält das flags-Byte. Dieses Byte steuert den Großteil der Validierungslogik auf Serverseite. Es ist ein Bit-Feld – jedes Bit hat eine eigene Bedeutung. Das UP-Flag (Bit 0, User Presence) zeigt an, dass der Nutzer den Authenticator aktiv bedient hat – den YubiKey-Knopf gedrückt, das Gerät entsperrt, eine Geste ausgeführt. Es muss laut Spezifikation immer gesetzt sein; fehlt es, muss die RP die Antwort ablehnen. Das UV-Flag (Bit 2, User Verification) geht einen Schritt weiter: Es zeigt an, dass der Nutzer lokal verifiziert wurde, etwa durch Biometrie oder PIN. Server, die userVerification: "required" konfiguriert haben, müssen dieses Bit zwingend prüfen.
Für Synced Passkeys sind die beiden Bits BE (Bit 3, Backup Eligibility) und BS (Bit 4, Backup State) besonders relevant. BE zeigt an, ob das Credential überhaupt sync-fähig ist – also ob es sich um ein Multi-Device Credential handelt. BS zeigt an, ob es zum Zeitpunkt der Anfrage tatsächlich aktiv synchronisiert ist. Die Kombination BE=1, BS=1 bedeutet: aktiv synchronisiert. BE=1, BS=0 heißt: sync-fähig, aber aktuell nicht in der Cloud gesichert. BE=0 wiederum garantiert, dass das Credential Device-bound ist und das Gerät nie verlassen hat. Diese Unterscheidung ist für Hochsicherheitsszenarien relevant, in denen Synced Credentials bewusst ausgeschlossen werden sollen. Schließlich steuert das AT-Flag (Bit 6), ob attestedCredentialData in der authData vorhanden ist. Es wird bei der Registration gesetzt, nicht bei der Authentication.
// flags-Byte aus authData auslesen (authData ist ein Uint8Array)
function parseAuthDataFlags(authData) {
const flagsByte = authData[32];
return {
up: !!(flagsByte & 0x01), // Bit 0 – User Presence
uv: !!(flagsByte & 0x04), // Bit 2 – User Verification
be: !!(flagsByte & 0x08), // Bit 3 – Backup Eligibility
bs: !!(flagsByte & 0x10), // Bit 4 – Backup State
at: !!(flagsByte & 0x40), // Bit 6 – Attested Credential Data
ed: !!(flagsByte & 0x80), // Bit 7 – Extension Data
};
}Listing 4: flags-Byte aus authData auslesen, in JavaScript
Die Bytes 33 bis 36 enthalten den signCount – einen Big-Endian-Zähler, der bei jedem Authentifizierungsvorgang höher sein muss als der zuletzt vom Server gespeicherte Wert. Die Idee dahinter ist eine Art Klon-Detektion: Wäre ein privater Schlüssel kopiert worden, wäre der Counter irgendwann nicht mehr korrekt. Bei Synced Passkeys ist diese Logik allerdings kompromittiert. Da etwa ein iCloud-Passkey parallel auf iPhone, iPad und MacBook genutzt werden kann, ist ein konsistenter, monotoner Counter schlicht nicht gewährleistet. Viele Implementierungen setzen signCount deshalb dauerhaft auf 0. Server müssen das explizit behandeln. Wie genau, wird Teil 2 dieser Artikelserie klären.
Das letzte relevante Feld ist attestedCredentialData. Es ist nur bei der Registration vorhanden, wenn das Attested Credential Data Flag gesetzt ist. Es enthält drei Bestandteile, die für die serverseitige Speicherung direkt relevant sind. Die aaguid (16 Bytes) identifiziert das Authenticator-Modell, nicht die individuelle Instanz. Über den FIDO Metadata Service (MDS) kann die RP damit prüfen, welches Gerät oder welche Software das Credential erzeugt hat. Das ist relevant für Szenarien, in denen nur bestimmte Hardware akzeptiert werden soll. Die credentialId ist eine vom Authenticator erzeugte eindeutige ID, die der Server speichert und bei zukünftigen Authentifizierungen in allowCredentials übergibt. Und der credentialPublicKey enthält schließlich den Public Key im Format CBOR Object Signing and Encryption (COSE) (RFC 8152), CBOR-kodiert. Der alg-Parameter gibt den Algorithmus an: -7 steht für ES256 (Elliptic Curve Digital Signature Algorithm (ECDSA) über P-256 mit SHA-256), -257 für RS256, -8 für EdDSA. Dieser Schlüssel ist der einzige Wert, den die RP dauerhaft speichern muss. Alle zukünftigen Assertion-Signaturen werden gegen ihn validiert.
Die Architektur von FIDO2 ist strukturell überschaubar: drei Akteure, zwei API-Aufrufe, eine zentrale Datenstruktur. Relying Party, WebAuthn Client und Authenticator kommunizieren über klar definierte Schnittstellen: WebAuthn nach oben zur Webanwendung, CTAP2 nach unten zum Authenticator. Die authData zieht sich als gemeinsamer Nenner durch beide Ceremonies: Bei der Registration steckt sie im attestationObject, bei der Authentication ist sie direkt als authenticatorData enthalten. Wer das Byte-Layout kennt und weiß, welche Bits welche Validierungen auslösen, kann die Serverlogik direkt einordnen.
Der nächste Teil geht die Registration Ceremony nach §7.1 [9] Schritt für Schritt durch: Er zeigt, wie PublicKeyCredentialCreationOptions aufgebaut ist, wie das attestationObject validiert wird und welche Felder der Server in welcher Reihenfolge prüfen muss. Anschließend folgt die Authentication Ceremony nach §7.2 [10]: PublicKeyCredentialRequestOptions, Signaturvalidierung über authData || SHA-256(clientDataJSON) und der Umgang mit signCount bei Synced Passkeys.
URL dieses Artikels:
https://www.heise.de/-11364345
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Michael Traitov / Shutterstock.com)
Gotify 3.0.0 führt OpenID Connect für die Anmeldung ein, verschärft den Umgang mit API-Token und überarbeitet die Konfiguration.
Mit Gotify 3.0.0 erhält der selbst gehostete Benachrichtigungsdienst eine Anmeldung über OpenID Connect (OIDC), zusätzliche Absicherung für sensible Aktionen in der Weboberfläche und eine umfassend überarbeitete Konfiguration. Das Major-Release verändert zugleich mehrere Schnittstellen und Konfigurationswege, sodass Administratoren ihre Installationen vor dem Upgrade prüfen sollten.
Gotify ist ein Open-Source-Server zum Versenden von Push-Nachrichten an eigene Clients und Anwendungen. Der Dienst richtet sich vor allem an Administratoren und Entwickler, die Benachrichtigungen aus Skripten, Monitoring-Systemen oder eigenen Anwendungen ohne externe Push-Plattform betreiben wollen. Clients abonnieren dabei Anwendungen auf einem Gotify-Server und erhalten deren Nachrichten per API.
Die wichtigste neue Funktion ist die Unterstützung für OpenID Connect. Damit kann Gotify Nutzer über einen externen Identity Provider anmelden, etwa über Keycloak [1], authentik oder einen Unternehmens-Login, der OIDC bereitstellt. OIDC baut auf OAuth 2.0 auf und liefert der Anwendung zusätzlich eine standardisierte Identität des angemeldeten Nutzers.
Das vereinfacht den Betrieb in Umgebungen, die bereits zentrale Benutzerkonten und Single Sign-on einsetzen. Statt separate Gotify-Passwörter zu verwalten, können Administratoren den Zugriff an den vorhandenen Identity Provider anbinden. Laut Release Notes [3] haben die Entwickler im Zuge dieses Updates auch mehrere Sicherheitsprobleme behoben.
Für besonders kritische Änderungen führt Gotify zudem eine „Session Elevation“ ein. Für sensible Änderungen in der Weboberfläche müssen angemeldete Nutzer ihre Identität erneut bestätigen. Das soll verhindern, dass ein bereits geöffneter Login für kritische Eingriffe missbraucht wird. Auch Skripte, die Endpunkte für Client-Tokens aufrufen, können davon betroffen sein und müssen gegebenenfalls angepasst werden.
Die neue Version verschärft außerdem den Umgang mit Zugangstoken. Gotify zeigt API-Token künftig nur noch beim Erstellen oder Erneuern an. Bereits angelegte Token lassen sich anschließend nicht mehr über die API auslesen. Das reduziert das Risiko, dass ein Token versehentlich über API-Antworten, Protokolle oder eine kompromittierte Verwaltungsoberfläche preisgegeben wird.
Ergänzend speichert der Server Tokens nicht mehr im Klartext. Der verfügbare Schlüsselraum für Token steigt laut Changelog auf mehr als 128 Bit. Neu ist außerdem, dass Anwendungen eigene Token aktualisieren können. Nachrichten lassen sich nun auch mit einem Client-Token versenden.
Inaktive Clients und Sitzungen räumt der Server künftig automatisch auf. Das soll veraltete Einträge aus der Instanz entfernen und die Zahl unnötig fortbestehender Sitzungen begrenzen. Für die Weboberfläche verwendet Gotify zudem HTTP-only-Cookies statt Local Storage. Solche Cookies kann JavaScript im Browser nicht direkt auslesen, was den Schutz gegen den Abfluss von Sitzungsdaten bei Cross-Site-Scripting-Angriffen verbessert.
Ein Breaking Change betrifft die Konfiguration: Die Datei config.yml wird nicht mehr unterstützt. Stattdessen muss man ihre Einstellungen in das neue Umgebungsvariablen-Format überführen. Dafür liefert das Projekt mit gotify migrate-config ein eigenes Kommando mit; zugleich führt Version 3 eine CLI mit den Befehlen gotify serve, gotify version und gotify migrate-config ein.
Wer Listen oder Maps über Umgebungsvariablen setzt, muss ebenfalls die geänderte Syntax berücksichtigen. Auch API-Clients sollten überprüft werden: Die URL im Feld paging.next von Antworten mit Nachrichtenlisten ist nun ein relativer Pfad statt einer vollständigen URL. Clients müssen ihn daher relativ zur Serveradresse auflösen.
Weitere Änderungen betreffen vor allem den Betrieb: Das Logging setzt jetzt auf zerolog, Docker-Images enthalten OCI-Labels, und für Tests mit noch nicht veröffentlichtem Code stellt das Projekt ein Image mit dem Tag gotify/server:master bereit. Neue Zeitstempelfelder dokumentieren zudem die Erstellung von Nutzern, Clients, Anwendungen und Plugins.
URL dieses Artikels:
https://www.heise.de/-11370630
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: JHVEPhoto/Shutterstock.com)
Kunden wurden plötzlich astronomische Kosten für Amazon Web Services angezeigt. Dahinter steckt ein technischer Fehler.
So mancher Kunde von Amazon Web Services (AWS) dürfte Panik bekommen haben: Der Cloud-Dienstleister verschickte Hinweise zu Kosten teils in Billionenhöhe – Grund waren Probleme im internen Abrechnungssystem.
Mehrere Medien berichten über AWS-Kunden, denen in ihrer Kostenübersicht, der AWS Billing Console, plötzlich Beträge von mehreren Billionen US-Dollar für den laufenden Monat angezeigt wurden. Ein Betroffener hatte im Vormonat lediglich 200 US-Dollar, ein anderer nur 43 US-Cent bezahlt. Auch im Kontakt mit dem Kundensupport war es laut der britischen Zeitung The Guardian [1] zunächst nicht ganz einfach, die Sache aufzuklären.
Schließlich wendete der AWS-Support sich an die Öffentlichkeit und meldete am Freitag auf X [2], dass das Unternehmen Probleme mit inkorrekten Abrechnungsdaten untersuche. Erst am Sonntag konnte AWS dann die Ursache aufklären und das Problem beheben.
Ursache war wohl eine fehlerhafte „Konfigurationsänderung“ im AWS-Abrechnungssystem, wie Gizmodo unter Berufung [3] auf die AWS-Supportseite [4] berichtet. Hier hat Amazon aber mittlerweile alle Informationen zu dem Thema entfernt, per Wayback Machine [5] lassen sich zumindest die Aktivitäten während der Fehlerbehebung aber noch nachlesen. „Dieses System stützt sich bei der Berechnung der Einzelpostengebühren auf Daten zur Einheitenumrechnung“, erklärte AWS demnach weiter. Doch die Änderung habe dazu geführt, dass Aktualisierungen der Daten zur Einheitenumrechnung fehlschlugen, was zu überhöhten Einzelpostenkosten führte, die sich auf die Konsole für Abrechnung und Kostenmanagement auswirkten und Warnmeldungen zu Budget- und Kostenabweichungen auslösten. Letztere dürften vielen Kunden einen gewaltigen Schock verpasst haben. Auf X teilte AWS am Sonntagnachmittag mit [6], dass das Problem jetzt behoben sei.
URL dieses Artikels:
https://www.heise.de/-11370078
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Natalia Klenova / Shutterstock.com)
Kleine, aber interessante Meldungshäppchen vom News-Buffet zu Git Browser, Microsoft, Mirantis, Google, Flux, JetBrains, W3C, Gradle und OllyGarden.
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:
go get github.com/microsoft/agent-framework-go lässt sich die Go-Implementierung des KI-Agenten-Toolkits einem Go-Projekt hinzufügen.Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail [17].
URL dieses Artikels:
https://www.heise.de/-11363727
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Matthias Parbel / KI / iX)
Zwei OpenTelemetry-Experten erklären, warum zu viele Daten schaden – und wie ein Top-down-Ansatz die Zuverlässigkeit der Observability rettet.
Terabytes an Logs, Metriken und Traces landen täglich in den Observability-Backends großer Unternehmen – ohne dass jemand genau sagen kann, wofür. Genau an dieser Stelle setzte der Eröffnungsvortrag der Online-Konferenz Mastering Observability im April 2026 [1] an. Unter dem Titel „Weniger Sammeln, mehr Verstehen – hin zu proaktivem Reliability Engineering“ argumentierten Severin Neumann und Juraci Paixão Kroehling, dass Observability kein Tool-Wettrüsten ist, sondern ein Engineering-Problem. Nicht die Datenmenge entscheidet, sondern ob sich damit die Fragen beantworten lassen, die für die Zuverlässigkeit verteilter Systeme wirklich zählen.
Beide Speaker bringen einschlägige Erfahrung mit: Neumann, Head of Community bei Bronto, sitzt im OpenTelemetry Governance Committee [2] und pflegt als Co-Maintainer die Dokumentation des Projekts. Kroehling ist Mitgründer und CEO von OllyGarden, einer OpenTelemetry-nativen Plattform mit Fokus auf Telemetrie-Qualität, ehemaliger Jaeger-Maintainer und Schöpfer zentraler OTel-Komponenten wie Collector Builder und Operator. Ihre gemeinsame These: Viele Organisationen betreiben angstgetriebene Datensammlung nach dem Motto „erst alles erfassen, später entscheiden“.
Die Folgen dieses „Telemetry Hoarding“ sind konkret: steigende Kosten für Storage, Egress, Ingestion und Verarbeitung, wachsendes Misstrauen gegenüber den eigenen Daten sowie eine längere Mean Time to Repair (MTTR). Statt proaktivem Reliability Engineering bleiben Teams im dauerhaften Fire-Fighting-Modus stecken. Observability definieren die Vortragenden schlicht als die Fähigkeit, Fragen zu stellen und belastbare Antworten zu erhalten – die drei Signale Logs, Metriken und Traces sind dafür nur das Fundament.
Als Denkmodell dient das „2-Uhr-Szenario“: Ein Service bricht mitten in der Nacht zusammen, betroffen sind Nutzer in einer anderen Zeitzone. Welche Frage würde das Bereitschaftsteam um zwei Uhr morgens stellen – und beantwortet die vorhandene Telemetrie sie überhaupt? Diese Perspektive verschiebt den Fokus von „Was können wir alles sammeln?“ hin zu „Was muss ich wissen, damit Nutzer ihr Ziel zuverlässig erreichen?“.
Der vorgestellte Ansatz arbeitet sich von oben nach unten vor: von kritischen Nutzertransaktionen wie Login, Checkout oder Payment über die Service-Grenzen bis hinunter zur Infrastruktur mit Datenbanken, Queues und Netzwerk. Bei den Metriken bilden die Golden Signals – Latency, Traffic, Errors und Saturation – den Einstieg. Alerts sollen nur für Kennzahlen entstehen, die direkt die Zuverlässigkeit der Nutzerziele betreffen, und jeder Alert muss actionable sein, also eine klare Zuständigkeit und erwartbare Maßnahme mit sich bringen.
Traces bilden nach Ansicht der Referenten das Fundament der Strategie. Statt alles zu erfassen, empfehlen sie strategisches Sampling entlang kritischer Kundentransaktionen und selektives Sampeln übriger Pfade, um Datenvolumen und Kosten im Griff zu behalten. Auto-Instrumentierung deckt Dependencies und unterstützende Dienste wie Datenbanken, Message-Broker und externe APIs ab, während code-basierte Instrumentierung den Geschäftskontext einfängt – mit Attributen wie order_value, tenant_id oder feature_flag. Logs wiederum sollen nur gespeichert werden, wenn sie Evidenz liefern, verknüpft mit Trace- und Span-IDs statt generischer Meldungen wie [Error] Transaction failed.
Praktisch heißt das für DACH-Enterprises mit ihren oft strengen Compliance-Anforderungen: Debug-Spam, duplizierte Retry-Logs und Detailmetriken ohne Bezug zu Nutzerzielen fliegen raus. In die Sammlung gehören dagegen Golden Signals der kritischen Transaktionen, trace-basierte Geschäftsprozesse, strukturierte Fehlerlogs und knappe Ressourcenzustandsmetriken. Ein Big-Bang-Umbau ist dafür nicht nötig – der Einstieg über ein oder zwei geschäftskritische Services und eine schrittweise Governance blockiert das Tagesgeschäft am wenigsten.
Ein zentraler Baustein sind die OpenTelemetry Semantic Conventions. Sie sorgen dafür, dass Teams, Tools und Cloud-Anbieter dieselben Begriffe auf dieselbe Weise verwenden. Drei Regeln bringen das auf den Punkt: Konsistenz (etwa einheitlich deployment.environment.name = "production" statt uneinheitlichem env = "live"), Einmaligkeit (ein Name bezeichnet exakt eine reale Sache, nicht zwei Services mit service.name = "api") und Beständigkeit (statt service.name = "checkout-v1" besser service.name = "checkout" plus separates service.version).
Diese Konventionen heben nicht nur das Signal-Rausch-Verhältnis, sie machen Telemetrie auch für Maschinen verständlich. Gerade KI-Agenten und LLM-gestützte Debugging-Workflows sind auf semantisch klare, konsistente Daten angewiesen, um Kausalitäten erkennen zu können. Fehlen einheitliche Konventionen, entsteht ein „Semantic Sprawl“, der Interoperabilität zwischen Backends und Cloud-Diensten erschwert und einen Anbieterwechsel ohne komplette Re-Instrumentierung nahezu unmöglich macht.
Für die Umsetzung nennen die Speaker mehrere schnelle Gewinne. Auf Collector-Ebene lässt sich viel Ballast abwerfen: Ein Audit reduzierte 236 Resource-Attribute auf 85 tatsächlich benötigte, also über 60 Prozent weniger. Connection-Retries, die 300 identische Log-Einträge produzieren, schrumpfen per Deduplizierung auf einen Eintrag pro Vorfall. Auf SDK-Ebene helfen deklarative Konfiguration in YAML statt Boilerplate-Code sowie einheitliche SDK-Wrapper pro Sprache. Tools wie OpenTelemetry Weaver und KI-gestützte Agenten prüfen Code und Telemetrie automatisiert gegen die Conventions.
Severin Neumann ist Head of Community bei Bronto. Er beschäftigt sich seit vielen Jahren mit Observability, verteilten Systemen und der Frage, wie Engineering-Teams komplexe Softwarelandschaften zuverlässig betreiben können. Severin ist Mitglied des OpenTelemetry Governance Committees sowie Co-Maintainer der OpenTelemetry-Dokumentation und engagiert sich aktiv in der Open-Source- und Cloud-Native-Community.
Juraci Paixao Kroehling ist Mitbegründer und CEO von OllyGarden, einer OpenTelemetry-nativen Plattform, deren Schwerpunkt auf der Qualität der Telemetriedaten liegt. Er ist Mitglied des OpenTelemetry Governance Committee, ehemaliger Jaeger-Maintainer und Entwickler zentraler OpenTelemetry-Komponenten, darunter der Collector Builder und der Operator. Als CNCF-Botschafter mit Sitz in Berlin leistet Juraci seit den Anfängen einen Beitrag zum Cloud-Native-Ökosystem.
URL dieses Artikels:
https://www.heise.de/-11362984
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Summit Art Creations / Shutterstock.com)
Die IDE ermöglicht die direkte Verwendung von GitHub Copilot und kann mit neuen Versionen der Programmiersprachen Java, Kotlin und TypeScript umgehen.
JetBrains hat IntelliJ IDEA 2026.2 veröffentlicht. In der zweiten Hauptversion des Jahres sind Support für das anstehende Release Java 27 ebenso wie für Kotlin 2.4 und TypeScript 7.0 enthalten. Neuerungen bietet die Entwicklungsumgebung auch im Bereich des KI-gestützten Codings.
Nicht nur das auf Java, Kotlin und weitere Programmiersprachen ausgelegte IntelliJ IDEA hat ein Versionsupdate erhalten, sondern auch zahlreiche weitere JetBrains-IDEs. Noch in der Release-Candidate-Phase für Version 2026.2 befinden sich ReSharper und Rider.
Erst kürzlich ist TypeScript 7.0 erschienen [1]. In dem neuen Release sind Compiler und Language Server in Go geschrieben, was gemäß dem Hersteller Microsoft deutliche Geschwindigkeitsvorteile bringen soll [2]. IntelliJ IDEA 2026.2 kann mit dem neuen Release umgehen, und im Test hat sich laut JetBrains dadurch die Projektladezeit auf der Kibana-Codebasis von etwa zwölf auf etwa drei Sekunden reduziert.
Daneben kann IntelliJ IDEA nun mit den stabilen Sprachfeatures von Kotlin 2.4, ebenfalls aus dem Hause JetBrains, umgehen – darunter explizite Backing-Felder und Kontextparameter. Die für Herbst 2026 geplante Programmiersprachenversion Java 27 unterstützt IntelliJ IDEA ebenfalls, denn aus der IDE heraus lassen sich Early Access Builds installieren.
Im Bereich künstliche Intelligenz hat JetBrains einige Neuerungen zu bieten. Dank einer Partnerschaft zwischen JetBrains und Microsoft ist GitHub Copilot nun nativ in IntelliJ IDEA integriert und out-of-the-box zugänglich. Die Auswahl erfolgt über den Agent Picker im Chat, und die Authentifizierung geschieht via OAuth und das GitHub-Nutzerkonto. Ein aktives GitHub-Copilot-Abo wird hierfür vorausgesetzt.
Das Entdecken, Installieren und Verwalten benutzerdefinierter Agenten-Skills ist nun innerhalb von IntelliJ IDEA ebenfalls möglich. Wie JetBrains ausführt, seien einige der nützlichsten Skills bereits enthalten und im Skills-Manager markiert. Ein weiteres Update betrifft die im Editor vorhandene KI-basierte Codevervollständigung: Nun können Entwicklerinnen und Entwickler ihre eigenen, OpenAI-kompatiblen Modellanbieter mit der IDE verbinden.
Darüber hinaus hat JetBrains über 1300 Bugfixes und Usability-Verbesserungen umgesetzt – darunter allein 140, die Freezes und andere Performanceschwierigkeiten beheben. Details zu den Neuerungen in IntelliJ IDEA 2026.2 finden sich in den „What’s New [3]“- und „What’s Fixed [4]“-Blogeinträgen.
Neben IntelliJ IDEA stattet JetBrains auch seine weiteren spezialisierten Entwicklungsumgebungen schrittweise mit Version 2026.2 aus. Beispielsweise legt die JavaScript- und TypeScript-IDE WebStorm einen starken Fokus auf das neue TypeScript 7.0, während PhpStorm unter anderem das Aufsetzen eines PhpStorm-MCP-Servers für Terminal-AI-Sessions beschleunigt.
Die Updates in WebStorm [5], PhpStorm [6], CLion [7], GoLand [8] und dem IntelliJ-Scala-Plug-in [9] in Versionsnummer 2026.2 lassen sich den jeweiligen Blogeinträgen entnehmen.
URL dieses Artikels:
https://www.heise.de/-11369167
Links in diesem Artikel:
Copyright © 2026 Heise Medien
