Quellcode und Git-Repositories mit Zeitstempel sichern

Git-Commit-Daten zeigen nicht, wann dein Code existiert hat. Jeder kann sie auf einen beliebigen Wert setzen, und ein Rebase schreibt sie neu. Wenn ein Datum für deine Codebasis auch für Fremde, Auftraggeber oder ein Gericht tragen soll, nimm einen exakten Stand des Codes – meist ein ZIP eines getaggten Commits – und setze einen qualifizierten elektronischen Zeitstempel auf seinen Fingerabdruck. Nur der Fingerabdruck verlässt deinen Rechner, das funktioniert also auch für privaten und proprietären Code. Hier stehen das genaue Vorgehen, was es belegt und was nicht.

Allgemeine Information über Beweismittel – keine Rechtsberatung für einen konkreten Fall.

Warum deine Git-Historie kein unabhängiger Beleg für ein Datum ist

Git speichert bei jedem Commit zwei Daten, das Author-Datum und das Committer-Datum, und beide kommen vom Rechner, der den Commit erstellt. Niemand prüft sie. Wer vor einem Commit GIT_AUTHOR_DATE und GIT_COMMITTER_DATE setzt oder git commit --amend --date ausführt, bekommt eine Historie, die sagt, was er will. Interaktives Rebase, Squash-Merges und Cherry-Picks schreiben Daten ganz nebenbei bei normaler Arbeit um.

Wertlos ist die Historie deshalb nicht. Sie ist ein sehr guter Beleg dafür, wie der Code entstanden ist: kleine Schritte, Begründungen in Commit-Messages, Issues, Reviews, verworfene Branches. Für das Wann ist sie schwach, weil derjenige, der sich auf sie beruft, sie auch geschrieben haben könnte.

Gehostete Plattformen helfen, schließen die Lücke aber nicht. GitHub, GitLab und Bitbucket speichern, wann ein Push bei ihnen ankam – diese Daten liegen jedoch bei einem privaten Unternehmen, sind später oft schwer zu bekommen und verschwinden mit einem gelöschten Repository oder Konto. Ein Force-Push ersetzt, was vorher da war.

Was ein qualifizierter Zeitstempel hinzufügt

Ein qualifizierter elektronischer Zeitstempel wird von einem beaufsichtigten Vertrauensdiensteanbieter nach der EU-Verordnung eIDAS ausgestellt. Nach Artikel 41 Absatz 2 vermuten Gerichte in jedem Mitgliedstaat, dass Datum und Uhrzeit richtig sind und die erfassten Daten seitdem unverändert. Das Datum kommt nicht von dir – der Einwand, du hättest es selbst gesetzt, greift also nicht.

Der Zeitstempel ist an einen SHA-256-Fingerabdruck einer Datei gebunden. Ändert sich ein einziges Byte, passt der Fingerabdruck nicht mehr. Deshalb geht es im Folgenden darum, genau eine Datei auszuwählen und unverändert aufzubewahren.

Methode 1: ZIP eines getaggten Commits zeitstempeln (am stärksten)

1. Den Stand taggen, den du festhalten willst. git tag v1.4.0 (oder einen bereits getaggten Commit nehmen).
2. Genau diesen Stand exportieren. git archive --format=zip -o meinprojekt-v1.4.0.zip v1.4.0. Das Archiv enthält die versionierten Dateien dieses Commits und sonst nichts: keine .env, keine Build-Ausgabe, keine uncommitteten Änderungen.
3. Für dieses ZIP ein Zertifikat ausstellen. Der Fingerabdruck wird in deinem Browser berechnet; das ZIP selbst wird nicht hochgeladen. Dateien bis 500 MB sind möglich.
4. Das ZIP unverändert aufbewahren, neben dem Zertifikats-PDF und an mindestens zwei Orten. Nicht entpacken und neu packen: Ein neues Archiv mit identischen Dateien kann trotzdem einen anderen Fingerabdruck haben.

Warum ein ZIP und nicht der Ordner: Das Zertifikat erfasst genau eine Datei. Ein Archiv macht aus dem ganzen Verzeichnisbaum eine Datei, deren Fingerabdruck du später mit jedem SHA-256-Werkzeug nachrechnen kannst. Die Ausgabe von git archive kann sich zwischen Git-Versionen unterscheiden – genau deshalb bewahrst du das gestempelte Archiv auf, statt es später neu zu erzeugen.

Methode 2: einen Commit-Nachweis zeitstempeln (leichtgewichtig)

Wenn du viele Commits günstig datieren willst oder das Repository größer als 500 MB ist, schreib eine kurze Textdatei und stemple stattdessen diese:

repository: git@example.com:ich/meinprojekt.git
tag: v1.4.0
commit: 3f9c2e7d0a5b8c1e4f6a9d2b7c0e3f5a8b1d4c6e
tree: 9b2e4d6f8a0c1e3b5d7f9a1c3e5b7d9f0a2c4e6b
note: Release Candidate, auf Anfrage an Auftraggeber geschickt

Trag in die Zeilen für Commit und Tree die echten Werte aus git rev-parse v1.4.0 und git rev-parse v1.4.0^{tree} ein. Eine Git-Commit-ID ist ein Hash über den Tree, die Eltern-Commits und die Nachricht – sie bindet den Zeitstempel also an genau diesen Stand des Codes und an die gesamte Historie davor. Bewahre das Repository mit diesem Commit sicher auf; die Textdatei allein zeigt ohne es nichts.

Der Haken: Die Verbindung von der Textdatei zu deinem Code hängt an Gits eigenem Hashing. Die meisten Repositories verwenden für Objekt-IDs noch SHA-1, für das es bekannte Kollisionsangriffe gibt, auch wenn Git eine Erkennung für den bekannten Angriff mitbringt. Für einen routinemäßigen Meilenstein reicht das meist. Für die Version, auf die du dich im Streit am ehesten berufen würdest, nimm Methode 1 – dort erfasst der Zeitstempel die Dateien selbst.

Wann welche Methode

Privater und proprietärer Code

Der Fingerabdruck wird auf deinem Gerät berechnet. Solange du nicht ausdrücklich wählst, eine Kopie der Datei zu speichern, erhält StampR nur den Fingerabdruck, Dateiname und -größe sowie die Angaben, die du einträgst. Aus dem Fingerabdruck lässt sich der Code nicht zurückgewinnen. Bei proprietärem Code die Option zum Speichern und Anzeigen des Originals nicht anhaken: Ein gespeichertes Original wird auf der öffentlichen Seite des Zertifikats angezeigt.

Wähle Dateiname und Beschreibung mit derselben Sorgfalt – beide stehen auf dem Zertifikat. meinprojekt-v1.4.0.zip ist unproblematisch; ein Name, der ein unangekündigtes Produkt verrät, vielleicht nicht.

Was das nicht leistet

• Es zeigt nicht, dass du den Code geschrieben hast. Es zeigt, dass genau dieser Code zu diesem Zeitpunkt existierte und dass du ihn als deinen erklärt hast. Commit-Historie, Issues und Designnotizen zeigen die Arbeit daran.
• Es entscheidet nicht, wem der Code gehört. Schafft ein Arbeitnehmer in der EU ein Programm in Wahrnehmung seiner Aufgaben, ist ausschließlich der Arbeitgeber zur Ausübung aller wirtschaftlichen Rechte befugt, sofern vertraglich nichts anderes vereinbart ist (Richtlinie 2009/24/EG, Art. 2 Abs. 3; in Deutschland § 69b UrhG). Bei Freelance- und Agenturarbeit entscheidet der Vertrag. Ein Zeitstempel fixiert Daten, er setzt keine Vereinbarung außer Kraft.
• Es schützt keine Idee und keinen Algorithmus als solchen. Das EU-Software-Urheberrecht erfasst die Ausdrucksform eines Programms, nicht die zugrunde liegenden Ideen und Grundsätze (Richtlinie 2009/24/EG, Art. 1 Abs. 2). Patentfragen sind ein eigenes Thema, und eine Veröffentlichung kann sie beeinflussen.
• Es ersetzt keine Lizenz. Wenn du Code veröffentlichst, wähle und lege eine Lizenz bei; der Zeitstempel ist ein Beleg, keine Erlaubnis.

Einen Stand deines Codes zeitstempeln – das erste Zertifikat mit Konto kostet 4,90 €.

Später prüfen

Jeder kann das Zertifikat prüfen, ohne dir vertrauen zu müssen. sha256sum meinprojekt-v1.4.0.zip ausführen (macOS: shasum -a 256, Windows: Get-FileHash) und das Ergebnis mit dem Fingerabdruck auf dem Zertifikat vergleichen oder auf der Prüfseite eingeben. Stimmt er überein, ist die Datei Byte für Byte diejenige, die gestempelt wurde.

Weiterlesen

• Hunderte Dateien mit einem einzigen Zeitstempel sichern – die Manifest-Methode, wenn ein ZIP nicht praktikabel ist.
• Halten Zeitstempel-Zertifikate vor Gericht? – was die eIDAS-Vermutung im Streit bewirkt.
• Urheberschaft dokumentieren: alle Optionen im Vergleich – auch, wann ein Zeitstempel das falsche Werkzeug ist.

Häufige Fragen

Taugen Git-Commit-Daten als Beleg dafür, wann Code geschrieben wurde?

Man kann sie vorlegen, für das Datum sind sie aber schwach: Sie stammen vom Rechner, der den Commit erstellt, und lassen sich mit Umgebungsvariablen, Amend oder Rebase ändern. Für den Entstehungsweg sind sie ein starker Beleg und wirken am besten zusammen mit einem unabhängigen Datum wie einem qualifizierten Zeitstempel.

Muss ich meinen Quellcode hochladen?

Nein. Der SHA-256-Fingerabdruck wird in deinem Browser berechnet und nur er wird übertragen, es sei denn, du wählst, eine Kopie der Datei zu speichern. Bei proprietärem Code keine Kopie speichern.

Soll ich das ZIP oder den Commit-Hash zeitstempeln?

Das ZIP eines getaggten Commits ist die stärkere Variante, weil der Zeitstempel die Dateien direkt erfasst. Eine Textdatei mit der Commit-ID ist für regelmäßige Meilensteine günstiger und erfasst die gesamte frühere Historie, ihre Verbindung zum Code hängt aber an Gits eigenem Hashing.

Reicht der Push-Zeitpunkt auf GitHub?

Er ist ein nützlicher ergänzender Beleg, liegt aber bei einer privaten Plattform, ist später oft schwer zu bekommen und verschwindet, wenn Repository oder Konto gelöscht werden. Einen qualifizierten Zeitstempel hast du selbst in der Hand, und EU-Gerichte vermuten sein Datum als richtig.

Zeigt ein Zeitstempel, dass mir der Code gehört?

Nein. Wem Code gehört, hängt davon ab, wer ihn geschrieben hat, und von Arbeits- oder Freelance-Verträgen. Der Zeitstempel fixiert, dass genau dieser Code zu einem bestimmten Zeitpunkt existierte und dass du ihn als deinen erklärt hast.

Wie oft sollte ich zeitstempeln?

An den Zeitpunkten, auf die du dich später berufen könntest: bevor du Code jemand anderem gibst, vor einem Lizenzwechsel, am Ende eines Auftrags und bei großen Releases. Dazwischen bietet sich ein monatlicher Commit-Nachweis an.