Automatisiertes Git-Timestamping: Wie eine GitHub App jeden Commit verankert

Du pushst einen Commit, der zählt – den Kern eines Features, für das du wirst beweisen müssen, dass du es zuerst gebaut hast. Beim manuellen Ansatz ist genau das der Moment, in dem dein Workflow bricht. Du hältst an, wechselst den Kontext und beginnst ein kleines Ritual aus lokalem Tooling und Proof-Handling, um den Commit an einen Zeitpunkt zu binden. Dann machst du es beim nächsten Commit wieder, und beim übernächsten, bis zu dem Tag, an dem du es vergisst.

Das ist die manuelle Timestamping-Falle. Prior-Art-Nachweise sind nur so stark wie ihre Dichte und ihre Regelmäßigkeit, und menschliche Prozesse sind weder das eine noch das andere. Entwickler überspringen den Schritt im Stress, konfigurieren ihn auf einer neuen Maschine falsch oder richten ihn nie in dem Repository ein, das sich am Ende als entscheidend erweist. Lücken in der Kette sind genau das, wonach gegnerische Anwälte oder Auditoren suchen.

Dieser Artikel handelt davon, den Menschen vollständig aus diesem Kreislauf zu entfernen – mit automatisiertem Git-Timestamping über eine GitHub App. Eine Installation, und jeder Commit in einem überwachten Repository wird nächtlich mit einem Fingerabdruck versehen und in Bitcoin verankert – von einer Maschine, nach Zeitplan, ohne dass jemand einen Befehl eintippt.

Dies ist eine Automatisierungs-Anleitung, kein Kryptografie-Tiefgang. Zum Warum siehe Protecting Intellectual Property: A Guide for Software Developers und Prior Art Protection for Software Startups: A Guide. Zu den Mechanismen, wie du später einen Proof prüfst, siehe Verify Code Timestamps Without Sharing Your Source Code.

(Zur Einordnung: Der rohe Ansatz besteht darin, OpenTimestamps-Tooling manuell pro Commit auszuführen und deine eigenen Calendar-Submissions zu verwalten. Das ist der harte Weg. Alles Folgende ist der automatisierte Weg.)

Einmalige Einrichtung: Installiere die GitHub App und vergiss sie

Timestamp GIT ist ein Managed SaaS rund um eine GitHub App. Du installierst sie einmal für ein Repository oder eine ganze Organisation, und die Automatisierung übernimmt.

Es gibt zwei Deployment-Modi, und du wählst danach, wie viel Zugriff du gewähren willst:

Standard Mode (GitHub App). Die GitHub App liest nur den HEAD-Commit-Hash deines überwachten Repositorys – automatisch, bei jedem Push. Proofs werden in einen dedizierten Branch desselben Repos oder in ein separates Shadow-Repository geschrieben. Da GitHubs Berechtigungsmodell keinen Scope „nur Commit-Hash" bietet, erfordert dieser Modus Read-only-Zugriff auf das Quell-Repo und Read-write-Zugriff auf das Ziel-Repo, in dem die Proofs landen.

Enterprise ZK Mode (GitHub Action). Der Erfassungsschritt wandert in deine eigene CI. Eine 12-zeilige GitHub Action läuft auf deinen Runnern, extrahiert den HEAD-Hash und pusht nur diesen Hash an die Timestamp GIT API. Der Trade-off ist explizit: Du behältst den Lesezugriff bei dir, und Timestamp GIT benötigt Read-write-Zugriff nur auf das Ziel-Repo. Kein Quellcode und kein Repository-Lesezugriff überschreiten jemals die Grenze.

Zwei Dinge sind zur Einrichtung erwähnenswert:

• Auf Entwicklermaschinen wird nichts installiert. Keine CLI, kein lokaler Daemon, keine Konfigurationsdrift pro Laptop. Die App läuft auf GitHubs Infrastruktur und unserem Backend; die Action läuft auf GitHub-gehosteten oder selbst gehosteten Runnern.
• Es gibt keine laufende Konfiguration. Nach der Installation erkennt die App neue Commits über Webhooks. Niemand muss sich irgendetwas merken.

Du kannst nach der Installation auf deiner Repositories-Seite einsehen und verwalten, welche Repositories überwacht werden.

Die automatisierte Pipeline: Vom Commit zum Bitcoin-Anker

Sobald die App installiert ist, geschieht Folgendes zwischen git push und dem Erscheinen einer unveränderlichen Proof-Datei in deinem Repo.

1. Commit-Erkennung und Batching

Ein Webhook wird bei neuen Commits ausgelöst. Die App – oder deine Action im Enterprise ZK Mode – extrahiert den Commit-Hash und legt ihn in einem In-Memory-Key-Value-Store ab. Dieser Store ist eine Queue, kein Ledger; er existiert einzig, um Hashes zu sammeln, bis der nächtliche Batch läuft.

Nur der Hash bewegt sich. Nie der Diff, nie die Dateiinhalte, nie die Branch-Historie.

2. Der Mitternachts-Cron-Worker

Jede Nacht nimmt ein Worker jeden ausstehenden Hash auf und:

1. Gruppiert sie nach Repository und schreibt eine Manifest-Datei (.txt) pro Repo.
2. Baut einen Merkle-Baum nativ über den Batch.
3. Erstellt OpenTimestamps-Proofs unter Verwendung öffentlicher Calendar-Server.
4. Verankert die Merkle-Wurzel in der Bitcoin-Blockchain.

Der letzte Schritt ist der, der den Nachweis unveränderlich macht. Sobald die Wurzel in einem Bitcoin-Block bestätigt ist, kann keine Instanz – einschließlich Timestamp GIT – sie nachträglich ändern oder fälschen.

3. Proof-Auslieferung

Nach der Verankerung werden das Manifest und die entsprechenden .ots-Belegdateien zurück in dein Repository gepusht, entweder in einen dedizierten Timestamps-Branch oder in ein Shadow-Repository.

Plane dafür ein paar Stunden ein. Die Bitcoin-Bestätigung dauert typischerweise etwa 3 Stunden, sodass Proofs in der Regel einige Stunden nach dem nächtlichen Lauf eintreffen, nicht sofort.

Enterprise ZK Mode: der einzige Modus mit einer Workflow-Datei

Dies ist die einzige Stelle, an der du jemals YAML anschaust. Der Setup-Wizard generiert den Workflow mit vorausgefülltem Endpoint und Secret; er sieht ungefähr so aus:

name: Timestamp commit hash
on: [push]
jobs:
  anchor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - name: Send HEAD hash to Timestamp GIT
        env:
          TSG_ENDPOINT: ${{ secrets.TIMESTAMPGIT_ENDPOINT }}
        run: curl -fsS -X POST "$TSG_ENDPOINT" --data "$(git rev-parse HEAD)"

Das ist die gesamte Integration. Es gibt eine dedizierte Anleitung in GitHub Action for Commit Timestamping: Setup Guide, wenn du bei diesem Modus tiefer einsteigen willst.

Benutzerdefinierte Pipelines: die ZK Commit API

Wenn du das Timestamping in etwas anderes als den Standardablauf einbetten musst, akzeptiert die ZK Commit API Commit-Hashes direkt. Sie wird mit HMAC authentifiziert – der Hash-Wert aus der signierten URL muss die Anfrage begleiten –, sodass eine allein durchgesickerte URL nicht ausreicht, um in dein Ledger zu schreiben.

Für Read-only-Automatisierung sind die öffentlichen Status-Endpoints einfacher:

# Last anchored Bitcoin block for a repo
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo

# Total stamped commit count
curl -s https://timestampgit.dev/api/statusCount/your-org/your-repo

# Combined summary (what the Shields.io badge consumes)
curl -s https://timestampgit.dev/api/statusSummary/your-org/your-repo

Monitoring und Fehlerbehandlung

Automatisierung, die du nicht auditieren kannst, ist keine Automatisierung, der du in einem Streitfall vertrauen kannst. Timestamp GIT legt den Zustand deiner Proof-Kette an drei Stellen offen.

Das öffentliche Status-Dashboard

/status/{user}/{repo} zeigt die Proof-Langlebigkeit, das früheste Ankerdatum, die tägliche Regelmäßigkeit sowie die Bitcoin-Block- und Transaktionsdaten hinter jedem Anker. Es gibt eine Kalender-Heatmap, damit Lücken visuell offensichtlich sind, plus herunterladbare Audit-CSV- und PDF-Zertifikat-Exporte.

Regelmäßigkeit ist die Metrik, die du im Auge behalten solltest. Eine Heatmap mit Löchern ist eine schwächere Prior-Art-Story als eine lückenlose.

Verifizierungs-Badges

Du kannst Shields.io-Badges in deine README einbetten, um den Verifizierungsstatus öffentlich anzuzeigen. Das Widget unter /connected/{user}/{repo} liefert dir eine Live-Vorschau und das Markdown-Snippet, und /api/badgeLink/{user}/{repo} gibt die Badge-URLs und das Snippet programmatisch zurück.

Private Repositories hängen ein verschlüsseltes HMAC an die Badge- und Status-URLs an, beschränkt auf die Server-Instanz. Das bedeutet, das Badge wird weiterhin gerendert, während nur autorisierte Nutzer die zugrunde liegenden Statusdaten auflösen können.

Wenn ein nächtlicher Lauf fehlschlägt

Der wahrscheinlichste Fehler ist eine Bitcoin-Netzwerküberlastung, die die Bestätigung verzögert. Das System wiederholt den Versuch, statt den Batch zu verwerfen. Prüfe den Zustand über das Dashboard oder über die API, wenn du dies in dein eigenes Alerting einbindest:

# Confirm the latest anchored block; a stale value means the last run didn't land
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo | jq .

Wenn du zeitpunktbezogene Nachweise für die Compliance benötigst, zieh die Artefakte direkt:

# Full audit ledger as CSV
curl -sO https://timestampgit.dev/api/audit/your-org/your-repo

# PDF certificate for a specific date
curl -sO https://timestampgit.dev/api/report/your-org/your-repo/2026-10-04

Jeder kann außerdem den Zeitstempel eines einzelnen Tages unabhängig über /verification/{user}/{repo}/{date} verifizieren, wobei die vollständige Merkle-Kettenberechnung lokal im Browser stattfindet. Niemand – einschließlich Timestamp GIT – sieht, was du verifizierst.

Air-gapped-Umgebungen

Wenn deine Sicherheitsrichtlinie einen Managed Service überhaupt nicht zulässt, wird Timestamp GIT als Docker-Image ausgeliefert. Ein Quick-Start-Docker-Compose-Setup sieht so aus:

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

Die Anwendung ist nach dem Start unter http://localhost:8080 verfügbar, und ein Setup-Wizard führt dich beim ersten Start durch das Verbinden deiner GitHub App und die Konfiguration der Instanz. Eine zeitlich begrenzte Demo-Lizenz zur Evaluierung ist über die Docker-License-Seite erhältlich. Self-Hosted Blockchain Timestamping with Docker behandelt diesen Weg im Detail.

Best Practices für automatisiertes Timestamping

• Commite regelmäßig, in vernünftig großen Blöcken. Jeder Commit fügt dem täglichen Merkle-Baum ein Blatt hinzu. Eine dichte Kette ist ein stärkerer Prior-Art-Nachweis als vier riesige Commits pro Quartal.
• Schreibe aussagekräftige Commit-Nachrichten. Nur Hashes werden mit einem Zeitstempel versehen, aber während eines Audits wirst du Proofs den Features zuordnen. Gute Nachrichten machen diese Zuordnung trivial.
• Richte Alerting bei veralteten Ankern ein. Ein grünes Badge sollte bedeuten, dass ein kürzlicher Lauf erfolgreich war, nicht dass irgendwann im März einmal ein Lauf stattgefunden hat.
• Lass den Workflow in Ruhe. Das größte Risiko beim automatisierten Timestamping ist, dass jemand die Pipeline „verbessert". Das Standard-Setup hat aus gutem Grund keine manuellen Schritte.
• Greife zu Enterprise ZK Mode, wenn dein Quellcode nicht gelesen werden darf. Wenn die Compliance es verbietet, einem Dritten Lesezugriff auf das Repository zu gewähren, führe die Action auf deinen eigenen Runnern aus.
• Sag deinem Team, dass es automatisch ist. Ingenieure, die glauben, Timestamping sei eine manuelle Aufgabe, werden es irgendwann manuell versuchen, und so entstehen doppelte oder fehlerhafte Einträge.

Du kannst bei timestampgit.dev starten – installiere die App, verbinde ein Repository und lass den ersten nächtlichen Batch laufen.

FAQ

F: Muss ich meinen Git-Workflow ändern, um automatisiertes Timestamping zu nutzen? A: Nein. Sobald du die Timestamp GIT GitHub App installierst, erkennt sie neue Commits automatisch über Webhooks und versieht sie nächtlich mit Zeitstempeln. Du committest wie gewohnt weiter – keine zusätzlichen Befehle oder Schritte.

F: Was passiert, wenn ich mehrere Branches oder Repositories verwende? A: Die GitHub App überwacht alle Branches in den Repositories, für die du Zugriff gewährst. Du kannst auch konfigurieren, welche Repositories überwacht werden. Bei mehreren Repositories erhält jedes sein eigenes Manifest und seine eigenen Proof-Dateien.

F: Wird mein Quellcode jemals gegenüber Timestamp GIT offengelegt? A: Nein. Im Standard Mode liest die App nur den HEAD-Commit-Hash – niemals deinen Quellcode. Im Enterprise ZK Mode pusht eine GitHub Action auf deiner Infrastruktur nur den Commit-Hash an unsere API, sodass dein Code deine Umgebung nie verlässt.

F: Wie lange dauert es, bis ein Commit mit einem Zeitstempel versehen ist? A: Commit-Hashes werden gebündelt und einmal pro Nacht in Bitcoin verankert. Nach dem nächtlichen Lauf dauert es typischerweise etwa 3 Stunden, bis die Bitcoin-Transaktion bestätigt ist, wonach die .ots-Proof-Dateien zurück in dein Repository gepusht werden.

Fazit

Manuelles Timestamping scheitert aus demselben Grund, aus dem alle manuelle Compliance scheitert: Es hängt davon ab, dass ein Mensch sich jedes Mal, für immer, daran erinnert. Die GitHub App beseitigt diese Abhängigkeit. Installiere sie einmal, und jeder Commit in deinen überwachten Repositories wird mit einem Fingerabdruck versehen, gebündelt, Merkle-verwurzelt und nach nächtlichem Zeitplan in Bitcoin verankert – mit Badges, einem öffentlichen Status-Dashboard, einer Audit-CSV, PDF-Zertifikaten und browser-lokaler Verifizierung als Rückhalt.

Wenn du das für ein Team evaluierst, beginne mit einem einzelnen privaten Repository und beobachte, wie sich die Heatmap der ersten Woche füllt. Entscheide dann, wie weit du es ausrollst.

Installiere die GitHub App, verbinde dein erstes Repo und lass den Mitternachts-Worker den Rest erledigen.

Verwandte Beiträge

• Protecting Intellectual Property: A Guide for Software Developers
• Prior Art Protection for Software Startups: A Guide
• GitHub Action for Commit Timestamping: Setup Guide