#cosign

Ein Mesh ist auf dem Whiteboard immer gesund. Ein paar Kreise, einige Linien dazwischen, vielleicht noch eine Wolke für „das Internet“ — fertig ist das dezentrale Netz. Interessant wird es erst, wenn man eine Linie wegradiert. Oder drei. Wenn ein Knoten umzieht, eine Adresse nur aus einem privaten Netz erreichbar ist, UDP plötzlich verschwindet und niemand mehr zuverlässig sagen kann, welcher Weg zum Ziel noch existiert.

Genau dort beginnt fabric. Das Projekt untersucht, ob sich aus wenigen, bewusst begrenzten Bausteinen ein Peer-to-Peer-Netz zusammensetzen lässt, das neue Teilnehmer sicher aufnimmt, seine Nachbarn selbst entdeckt, indirekte Wege lernt und veraltete Routen wieder überprüft. Nicht als fertiges Produkt und nicht als Versprechen, jedes kaputte Netz magisch zu reparieren, sondern als Machbarkeitsstudie für Discovery und Auto-Healing: ausführbar, testbar und offen genug, dass auch die Lücken sichtbar bleiben.

In Radicle CI — eine Pipeline, die auf Patches reagiert habe ich den Plan beschrieben: Meine Seed-Node läuft in-cluster und führt einen Event-Stream — jede neue Patch-Ref, jedes COB-Update wird sichtbar. Ein CI-Broker abonniert diesen Stream, übersetzt ein Patch-Event in einen Build und schreibt das Ergebnis zurück auf den Patch. Sauberes Diagramm, klare Idee, ein offenes Trust-Problem, das ich für lösbar hielt.

Was dieser Beitrag erzählt, ist die Lücke zwischen dem Diagramm und einem grünen Häkchen. Sie war größer, als mir lieb war. Zwischen „der Broker ist deployt" und „der Broker baut wirklich ein signiertes Image" lagen rund zwei Dutzend Commits, die fast alle fix: heißen — und jeder davon steht für eine Wand, gegen die ich gelaufen bin. Kein Architektur-Pitch, sondern ein Reisebericht durch Entrypoints, die nicht stimmen, durch Flux, das meine Shell-Variablen frisst, durch rootless buildah, das in Kubernetes prinzipiell nicht funktioniert, und durch einen Kernel, der meinen QEMU-Handler immer wieder vergaß.

In Von SourceHut zu Radicle ist der Lab-Code in eine Peer-to-Peer-Forge umgezogen: keine zentrale Instanz mehr, Patches und Issues leben als signierte Collaborative Objects (COBs), Flux deployt vom kanonischen main. Ein Faden blieb dort offen — und genau um den geht es hier: Radicle ist eine Forge, kein CI-System. Der Code liegt P2P, der Build aber noch nicht.

„Container-Image“ ist im Sprachgebrauch fast zum Synonym für „Docker“ geworden — dabei ist das Format längst von Docker entkoppelt und in der Open Container Initiative (OCI) standardisiert. Dieser Beitrag erklärt, was das konkret bringt, warum meine Build-Pipeline deshalb mit Skopeo und Crane statt docker push arbeitet, und wie ich meine bisherige Harbor-Registry gegen das deutlich schlankere Zot getauscht habe.

Wer eigene Container-Images baut und in einer eigenen Registry hält, hat ein Vertrauensproblem in petto: Woher weiß der Cluster, dass ein Image wirklich aus meiner Pipeline stammt und nicht unterwegs manipuliert wurde? Meine Antwort ist eine geschlossene Kette aus zwei Hälften — cosign signiert in der CI, Kyverno verifiziert im Cluster und lässt nichts Unsigniertes durch.