GitHub hat erste Schritte angekündigt, um das Problem der schmuddeligen KI-Beiträge für Open-Source-Projekte anzugehen. Immer mehr Maintainer beklagen sich über derartige Pull Requests (PRs), deren Autorinnen und Autoren „möglicherweise nicht vollständig verstehen, was sie beitragen“ (Brecht Van Lommel, Blender). Das zu Microsoft gehörende GitHub steht als KI-Treiber im Zentrum der Kritik, hat nun aber eine Reihe von Maßnahmen in Planung.

Im Blogeintrag erkennt GitHub das Problem an: „Als Heimat von Open Source haben wir die Verantwortung, euch bei dem zu helfen, was auf euch zukommt.“ Als erste Maßnahme kündigt GitHub an, dass Maintainer PRs künftig einfach löschen können. Das gibt ihnen die Möglichkeit, schon anhand einer schnellen Prüfung AI Slop kurzerhand auszusortieren, um die Übersichtlichkeit des Repos zu erhalten. Das war auch eine der Hauptforderungen vieler überlasteter Projektverantwortlicher.

Weitere Funktionen, die GitHub derzeit erwägt, sind an Bedingungen geknüpfte PRs oder Triage-Tools, die PRs aussortieren, die Erfordernisse nicht erfüllen, die die Maintainer beispielsweise in einer Datei CONTRIBUTING.md manifestieren.

Vorangegangen war ein Aufruf von GitHub in der Community, in dem der Anbieter um Feedback bittet. Hier kündigt GitHub noch an, dass Maintainer PRs auf bestimmte Gruppen von Kontributoren oder für Mirrors einschränken können sollen.

Missmut in der Community steigt

In den vergangenen Wochen hatte die Kritik zugenommen: Gentoo Linux ist auf dem Weg, von GitHub zu Codeberg zu wechseln, und Curl stoppte das Bug-Bounty-Programm auf Hacker One aus ähnlichen Gründen. Zuletzt hatten sich Rémi Verschelde, Maintainer der Spiele-Engine Godot, und Brecht Van Lommel, Softwarearchitekt bei Blender, kritisch zu Wort gemeldet. Verschelde schreibt auf Bluesky: „Offen gesagt werden AI-Slop-PRs für die Godot-Maintainer immer anstrengender und demoralisierender.“ Gleichzeitig ruft er dazu auf, Godot besser finanziell zu unterstützen, um mehr Maintainer bezahlen zu können: Das „ist die einzige praktikable Lösung, die ich mir vorstellen kann.“

Weitere Vorschläge in den Kommentaren zu seinem Posting sind ein Authentifizierungssystem für Kontributoren oder ein Vorrang für erfahrene Entwickler mit ausreichend historischen GitHub-Beiträgen. Das hält auch Verschelde für möglich: „Ich möchte die Zugangsbarriere nicht erhöhen, aber wir haben vielleicht keine andere Wahl.“ An GitHub möchte er festhalten, aufgrund der guten Vernetzung der Projekte und nicht zuletzt wegen der kostenlosen CI.

Kritik an GitHub zielt in erster Linie auf die KI-treibende Politik von Microsoft, in deren Zentrum der Copilot steht. Alex McLean, Maintainer des Musik-Projekts Strudel, berichtet etwa: „Bei uns gab es keine KI-Bot-PRs mehr, seit wir von Microsoft GitHub zu Codeberg umgezogen sind. Ich vermute, dort gibt es keine Anreize dafür.“ Ein anderer Kommentator bezweifelt, dass GitHub ernsthafte Maßnahmen ergreifen will: „Das werden sie nicht. GitHub untersteht Microsofts KI-Team. Jedes neue Update auf der GitHub-Homepage hat einen KI-Bezug.“ Hier wird sich Microsoft beweisen müssen, um eine weitere Abwanderung einzudämmen.

Brecht Van Lommel schreibt im Blender-Blog neben seinem eingangs genannten Zitat: Für Maintainer ist es sinnvoll, neue Entwickler in das Projekt einzuweisen, um dieses voranzubringen, „auch wenn es für den Reviewer schneller gewesen wäre, die Änderungen selbst vorzunehmen (mit oder ohne KI). Daher sollten Reviewer wissen, ob sie mit einem Menschen zusammenarbeiten, damit sie entscheiden können, ob sich der Aufwand lohnt.“

(who)

In Lambda-Ausdrücken kann man in C# 14.0 jetzt Parameter-Modifizierer wie scoped, ref, in, out und ref readonly verwenden, ohne dabei den Datentyp benennen zu müssen.

Ein Beispiel: Für den Delegate

delegate bool Extract(string text, out T result);

musste man vor C# 14.0 Folgendes schreiben:

Extract ExtractOld = (string text, out int result) 
  => Int32.TryParse(text, out result);

Ab C# 14.0 können Entwicklerinnen und Entwickler im Lambda-Ausdruck die Nennung der Datentypen string und int weglassen, weil diese Datentypen aus dem Kontext bereits klar sind:

Extract ExtractNew = (text, out result) 
  => Int32.TryParse(text, out result);

Das geht allerdings nicht, wenn ein variadischer Parameter mit params zum Einsatz kommt:

Add AddOld = (out int result, params List data) 
  => { result = data.Sum(); return true; };

Nicht möglich ist also folgende Verkürzung:

Add AddNew = (out result, params data) 
  => { result = data.Sum(); return true; };

(rme)

Kyverno hat sich als Policy-as-Code-Werkzeug für Kubernetes etabliert, mit dem sich Richtlinien direkt als Kubernetes-Ressourcen definieren und durchsetzen lassen – von Validierung über Mutation bis hin zur Image-Verifikation. Das Tool begegnet so der wachsenden Komplexität beim Betrieb von Kubernetes-Clustern, indem es Sicherheits- und Compliance-Regeln als Code abbildet. Mit Version 1.17 vollzieht das CNCF-Projekt laut eigener Ankündigung nun einen strategischen Schnitt: Die in Version 1.16 eingeführte CEL-first-Architektur (Common Expression Language) verlässt den Beta-Status und wird zur stabilen Grundlage.

CEL-Policy-Typen erreichen GA-Status

Die zentrale Neuerung in Kyverno 1.17 ist laut CNCF-Blog die Promotion sämtlicher CEL-basierter Policy-Typen auf die API-Version v1. Damit gelten sie als stabil und produktionsreif. Im Einzelnen betrifft das: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, DeletingPolicy sowie PolicyException – jeweils inklusive ihrer Namespaced-Varianten (etwa NamespacedValidatingPolicy).

Die Common Expression Language ist dieselbe Ausdruckssprache, die der Kubernetes-API-Server selbst für seine nativen ValidatingAdmissionPolicies und MutatingAdmissionPolicies verwendet. Dem Kyverno-Entwicklungsteam zufolge soll der Wechsel zur CEL die Evaluierungsleistung spürbar verbessern und die Einarbeitungszeit für Plattform-Teams senken, da sie sich nur noch mit einer Sprache auseinandersetzen müssen.

Parallel dazu hat das Projekt die verfügbaren CEL-Funktionen erheblich ausgebaut. Neu hinzugekommen sind unter anderem Hash-Funktionen (md5, sha1, sha256), mathematische Rundung (math.round(value, precision)), das Dekodieren von X.509-Zertifikaten (x509.decode(pem)), Zufallsstring-Generierung, JSON- und YAML-Parsing sowie zeitbasierte Funktionen wie time.now() und time.toCron(timestamp), die etwa auch Policies für Wartungsfenster ermöglichen sollen.

Legacy-APIs werden abgekündigt – Migration empfohlen

Mit dem GA-Status der CEL-Policies geht eine klare Ansage an Bestandsnutzer einher: Laut der Ankündigung markiert Kyverno 1.17 die bisherigen Typen ClusterPolicy und CleanupPolicy offiziell als veraltet (deprecated). Diese JMESPath-basierten APIs bleiben in der aktuellen Version zwar funktionsfähig, sollen aber in einer künftigen Version vollständig entfallen – voraussichtlich noch im laufenden Jahr. Die Entwickler empfehlen ausdrücklich, neue Policies ausschließlich mit den CEL-basierten APIs zu schreiben, um den späteren Migrationsaufwand nicht weiter zu vergrößern.

Für Teams mit umfangreichen bestehenden Policy-Beständen stellt das Projekt einen Migrationsleitfaden bereit, der eine Feld-für-Feld-Zuordnung von Legacy-Konfigurationen zu den neuen Äquivalenten bieten soll. Beispielsweise wird das bisherige validate.pattern auf CEL-Ausdrücke in ValidatingPolicy abgebildet. Wer bislang ClusterPolicy-Regeln für Mutation, Validierung und Generierung in einem einzigen Objekt gebündelt hat, muss diese künftig auf die spezialisierten Typen ValidatingPolicy, MutatingPolicy und GeneratingPolicy aufteilen.

Multi-Tenancy: Namespaced Mutation und Generation

Bereits in Version 1.16 hatte Kyverno Namespaced-Varianten für Validierung, Cleanup und Image-Verifikation eingeführt. Version 1.17 schließt laut Ankündigung diese Lücke mit NamespacedMutatingPolicy und NamespacedGeneratingPolicy. Namespace-Besitzer können damit eigene Mutations- und Generierungsregeln definieren – etwa um automatisch Sidecar-Container zu injizieren oder Standard-ConfigMaps zu erzeugen –, ohne clusterweite Berechtigungen zu benötigen oder andere Mandanten zu beeinflussen. Damit soll echte Multi-Tenancy auf Policy-Ebene möglich werden.

Supply Chain Security und Observability

Für mehr Sicherheit in der Supply Chain bringt Kyverno 1.17 laut der Ankündigung Unterstützung für Cosign v3, um die Image-Verifikation mit dem sich weiterentwickelnden Sigstore-Ökosystem kompatibel zu halten. Die neuen YAML- und JSON-Parsing-Funktionen in CEL sollen es zudem erleichtern, komplexe Metadaten und Software Bill of Materials (SBOMs) innerhalb von Attestierungen zu prüfen.

Bei der Observability haben die Entwickler an zwei Stellschrauben gedreht: Ein neues Flag --allowedResults ermöglicht es, gezielt nur bestimmte Ergebnisse (etwa ausschließlich fehlgeschlagene Prüfungen) in Reports zu speichern. Das soll den Druck auf etcd in großen Clustern deutlich reduzieren. Darüber hinaus liefert Kyverno 1.17 laut dem Blogbeitrag standardmäßig detailliertere Latenz- und Ausführungsmetriken für CEL-Policies.

Neue Website und entkoppelte Entwickler-Tools

Neben den technischen Neuerungen hat das Kyverno-Projekt seinen gesamten Webauftritt auf Basis des Starlight-Frameworks neu gestaltet. Die überarbeitete Dokumentation umfasst eine nach Nutzererfahrung gestaffelte Struktur – vom Schnelleinstieg bis zur Referenz für fortgeschrittene Policy-Autoren. Der Katalog mit über 300 Beispiel-Policies soll sich nun nach Kategorie und Typ (CEL vs. JMESPath) filtern lassen.

Für Entwickler und Integratoren hat das Projekt seine Kernkomponenten entkoppelt: Die CEL-basierten APIs sind in ein eigenes Repository (kyverno/api) ausgelagert worden, was den Import von Kyverno-Typen in eigene Go-Projekte erleichtern soll. Zusätzlich steht ein dediziertes SDK-Projekt (kyverno/sdk) für den Bau eigener Controller und Tools bereit.

Roadmap: Einheitliche Tooling-Plattform angestrebt

Für die weitere Entwicklung skizzieren die Kyverno-Maintainer mehrere Schwerpunkte: Die verschiedenen Unterprojekte – CLI, Policy Reporter und Kyverno-Authz – sollen zu einer einheitlichen Plattform zusammenwachsen. Zudem will das Team automatisierte Performancetests etablieren und granulare Durchsatz- sowie Latenz-Daten bereitstellen, damit Plattform-Teams das Verhalten von Kyverno in Hochlast-Szenarien besser einschätzen können. Ein Upgrade von Version 1.16 auf 1.17 soll laut den Entwicklern unkompliziert sein, allerdings empfehlen sie, Manifeste auf die neue API-Version v1 umzustellen. Die bisherige v1beta1 werde für eine Übergangszeit weiter unterstützt.

(map)