Warum sollte ich mich nicht einfach auf Git-Commit-Daten verlassen?

Weil es sich um Metadaten handelt, die Ihre eigene Maschine schreibt. git commit --date, ein Rebase oder eine Uhreinstellung können jede beliebige Historie erzeugen, und das Ergebnis sieht völlig normal aus. Das ist intern akzeptabel, aber als Beweismittel schwach — und diese Schwäche wirkt sich gegen Sie aus, wenn Sie sich verteidigen, nicht nur, wenn Sie Ansprüche geltend machen.

Was genau sollte ich für einen Release zeitstempeln?

Ein deterministisches Artefakt statt eines Arbeitsbaums: ein git archive oder git bundle des getaggten Zustands, ein Build-Ergebnis oder ein Tarball mit reproduzierbarer Reihenfolge. Speichern Sie das Zertifikat neben dem Release und notieren Sie den Tag, damit jeder später das Archiv neu erstellen, hashen und mit dem Register vergleichen kann.

Verlässt der Code unsere Maschinen?

Nein. Das Artefakt wird in Ihrem Browser gehasht, und es wird nur der resultierende 64-stellige Hashwert übermittelt; es gibt keinen Endpunkt, der die Datei annimmt. Sie können den Hash auch selbst mit jedem Standardtool generieren — unser Mehrwert liegt darin, ihn an eine öffentliche Transaktion zu verankern, nicht darin, etwas zu empfangen.

Wie unterscheidet sich das von einem signierten Git-Tag?

Ein signierter Tag beweist, wer ihn erstellt hat, und dass die Inhalte unverändert sind, aber das Datum ist weiterhin das, was die Maschine des Unterzeichners behauptet. Eine Verankerung im Register fixiert die Zeit unabhängig davon. Beide ergänzen sich gut: Signieren Sie den Tag für Urheberschaft und Integrität, versehen Sie das Artefakt mit einem Zeitstempel für das Datum.

Blockchain-Zeitstempel für Softwareteams

Die Lücke in Ihrer bestehenden Historie

Git zeichnet viel auf, präzise und für ingenieurtechnische Zwecke geeignet. Als Beweismittel hat es jedoch eine spezifische Schwäche: Die Daten können Sie selbst schreiben.

git commit --date, ein interaktives Rebase oder eine Uhreinstellung — allesamt erzeugen sie eine Historie, die völlig normal aussieht und behauptet, was immer Sie wollen. Das ist intern in Ordnung. Gegen einen motivierten Gegner ist das jedoch kaum ein stichhaltiger Anspruch, und dieselbe Schwäche wirkt sich auch gegen Sie aus, wenn Sie sich verteidigen.

Die eigenen Zeitstempel eines gehosteten Repositorys sind besser, gehören aber einer Plattform, können bei Verlust des Accounts verloren gehen und lassen sich von externen Personen nicht unabhängig verifizieren.

Was Sie verankern sollten

Releases. Der Hash eines Release-Archivs oder eines Repository-Bundles, versehen mit einem Zeitstempel bei jedem Release. Das schafft einen datierten, manipulationssicheren Nachweis darüber, was genau ausgeliefert wurde. Das ist nützlich bei einer Verletzungsklage und ebenso nützlich bei der Verteidigung dagegen — nachzuweisen, dass Ihre Version dem kopierten Code vorausgeht, ist im Grunde derselbe Vorgang in umgekehrter Richtung.

Zustände vor der Offenlegung. Bevor Code an einen Kunden, einen Prüfer, einen Erwerber oder einen Treuhänder geht. Der Hashwert wird in Ihrem Browser berechnet und nur dieser Hashwert übermittelt. Das ist entscheidend, wenn der Code das Geschäftsgeheimnis ist — siehe Markenschutz vs. Urheberrecht für Quellcode, um zu verstehen, warum Geheimhaltung oft der eigentliche Schutzmechanismus ist.

Design- und Architekturdokumente. Häufig die wertvollsten und am wenigsten geschützten Artefakte, die ein Team besitzt.

Daten-Snapshots. Wenn Sie nachweisen müssen, dass ein Datensatz zu einem bestimmten Zeitpunkt in einem bestimmten Zustand war.

So setzen Sie es in der Praxis um

Hashen Sie das Artefakt, nicht den Arbeitsbaum. Das zuverlässige Muster ist ein deterministisches Archiv:

git archive oder git bundle für einen Repository-Zustand
Ein Build-Artefakt für einen Release
Ein Tarball für ein Verzeichnis, mit reproduzierbarer Reihenfolge, wenn Sie den Hash-Wert wiederholbar halten möchten

Versorgen Sie diese Datei anschließend mit einem Zeitstempel. Speichern Sie das Zertifikat zusammen mit dem Release und notieren Sie den entsprechenden Tag. Jeder kann später das Archiv neu erstellen, hashen und mit dem Register vergleichen.

Warum nichts hochgeladen wird

Bei proprietärem Code ist das Vertraulichkeitsgebot absolut, und ein Zeitstempeldienst, der die Datei haben will, ist ein Dienst, den Sie nicht nutzen können.

Hier wird die Datei in Ihrem Browser über die Web Crypto API gehasht, und es wird nur der 64-stellige SHA-256-Hashwert übermittelt. Es gibt keinen Endpunkt, der das Artefakt annimmt. Wenn Sie den Hash lieber selbst generieren möchten, erledigt das das kostenlose Hash-Tool lokal und erzeugt eine byteidentische Ausgabe wie shasum -a 256.

Was es beweist

Dass das Artefakt bis zu diesem Zeitpunkt existierte und sich nicht verändert hat. Es beweist nicht, wer es geschrieben hat, es ist kein Patent und es registriert auch kein Urheberrecht — siehe Existenznachweis vs. Urheberschaftsnachweis.

Das Urheberrecht an Ihrem Code entsteht automatisch. Was Ihnen meist fehlt, ist ein unanfechtbares Datum, und genau diese Lücke schließt dieser Ansatz.