#git

Kein Klartext-Secret kommt durch — pre-commit, gitleaks und SOPS

Permalink 3 min read Published:
 security  automation  #pre-commit #gitleaks #sops #secrets #git #gitops #shellcheck
Ein GitOps-Repo ist öffentlich, sobald man es vergisst. Drei Hooks sorgen dafür, dass ich gar nicht erst ein unverschlüsseltes Secret committen kann: gitleaks scannt auf Muster, ein SOPS-Hook verweigert Klartext in geschützten Pfaden, und ein lokaler Decrypt-Check stellt sicher, dass jede verschlüsselte Datei sauber entschlüsselt und alle Empfänger trägt.

Mein Lab-Repo ist öffentlich — abrufbar über meinen Radicle -Seed-Node seed.this-is-fine.io. Genau deshalb darf da nie ein Klartext-Secret hineinrutschen. Nicht „sollte nicht", sondern kann nicht: Drei pre-commit -Hooks fangen den Fehler ab, bevor er ein Commit-Objekt wird. Das ist die billigste Versicherung, die ich kenne — ein paar Zeilen YAML gegen einen Leak, den man nie ganz zurückholt.

Radicle CI — eine Pipeline, die auf Patches reagiert

Permalink 4 min read Published:
 infrastructure  #radicle #ci #p2p #forge #cosign #supply-chain #zot #kubernetes #git
Der Code des Labs liegt in einer P2P-Forge, die CI aber noch nicht: Builds laufen post-merge auf einer externen .build.yml. Wie ein Radicle-CI-Broker das schließt — er hört auf die Patch-Events der eigenen Seed-Node, baut und signiert in-cluster und schreibt das Ergebnis zurück auf den Patch. Plus das eigentlich harte Problem: Vertrauen in einer Forge ohne Owner.
Stand: Design/Roadmap. Issue 7f834f9 : „Wire Radicle CI once the lab repo is published (patches already wired)." Die Seed-Node läuft in-cluster, der Patch-Workflow steht — der CI-Broker ist das letzte fehlende Stück. Dieser Beitrag beschreibt, wie er andocken soll.

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.

Radicle: Eine Forge, die niemandem gehört

Permalink 4 min read Modified: (UPDATED)
 infrastructure  #radicle #git #sourcehut #p2p #forge #open-source #ci
Was eine peer-to-peer-Git-Forge für die Open-Source-Welt bedeutet — und warum ich gerade all meine Repos von SourceHut zu Radicle umziehe

Git ist von Haus aus dezentral — aber die Art, wie wir damit zusammenarbeiten, ist es längst nicht. Pull Requests, Issues, Reviews: All das lebt auf zentralen Plattformen, die das Protokoll selbst gar nicht braucht. Radicle holt diese Kollaborationsschicht zurück ins dezentrale Modell, und genau deshalb ziehe ich gerade nicht nur mein Lab, sondern alle meine Repos dorthin um — und das sind einige, überwiegend die Quellen meiner Container-Images.