Was genau soll ich für ein Release hashen?

Ein deterministisches Artefakt statt eines Working Trees — ein git-Archiv oder git-Bundle des getaggten Zustands oder eine reproduzierbare Build-Ausgabe. Speichern Sie das Zertifikat zusammen mit dem Release und notieren Sie den Tag, und bewahren Sie das Artefakt Byte für Byte auf, da das Neuerstellen eines Archivs selten identische Bytes erzeugt.

Verlässt der Code unsere Maschinen?

Nein. Das Artefakt wird in Ihrem Browser gehasht, und nur der 64-stellige Hashwert wird übertragen; es gibt keinen Endpunkt, der die Datei akzeptiert. Sie können den Hashwert auch mit Ihrer eigenen Tooling berechnen und diesen Wert zeitstempeln — der Dienst fügt den Anker hinzu, nicht das Hashing.

Software-Release mit Zeitstempel versehen

Q: Ist das anders als das Signieren eines Git-Tags?

Ja, und sie ergänzen sich. Ein signiertes Tag beweist, wer es erstellt hat, und dass die Inhalte unverändert sind, aber sein Datum ist weiterhin das, was die Maschine des Unterzeichners behauptet hat. Ein Registeranker fixiert die Zeit unabhängig von jedermann. Signieren Sie für Urheberschaft und Integrität, Zeitstempel für das Datum.

Versionsverwaltung bietet Ihnen eine exzellente Historie und ein schwaches Datum. Das Verankern eines Releases behebt dieses zweite Problem in etwa einer Minute pro Release.

Warum Git-Daten nicht ausreichen

Commit-Zeitstempel werden von der commitenden Maschine geschrieben. Ein interaktives Rebase, eine Uhrzeitanpassung oder die übliche --date-Flagge können jede beliebige Historie erzeugen, und das Ergebnis sieht völlig normal aus.

Intern ist das in Ordnung. Als Beweismittel ist es jedoch dünn, und die Schwäche wirkt in beide Richtungen — sie ist ebenso wenig hilfreich, wenn Sie sich gegen einen Anspruch verteidigen, statt ihn zu erheben.

Die eigenen Zeitstempel einer gehosteten Plattform sind besser, gehören aber der Plattform, verschwinden mit dem Konto, und ein Außenstehender kann sie nicht unabhängig überprüfen.

Was Sie verankern sollten

Nicht den Working Tree. Ein deterministisches Artefakt, dessen Bytes Sie später reproduzieren können:

git archive --format=tar.gz -o release-v1.4.0.tar.gz v1.4.0

oder ein Bundle, das sowohl Historie als auch Inhalt erfasst:

git bundle create release-v1.4.0.bundle v1.4.0

oder die Build-Ausgabe selbst, wenn Ihr Build reproduzierbar ist.

Hashen Sie dann diese Datei und versehen Sie den Hashwert mit einem Zeitstempel.

Die Schritte

Erstellen Sie das Artefakt vom Tag aus, nicht aus Ihrem Arbeitsverzeichnis.
Hashen Sie es — shasum -a 256 oder das Browser-Tool, das identische Ergebnisse liefert.
Versehen Sie den Hashwert mit einem Zeitstempel. Die Datei wird in Ihrem Browser gehasht, und nur der Hashwert wird übertragen, was relevant ist, wenn der Code proprietär ist.
Speichern Sie das Zertifikat zusammen mit dem Release und notieren Sie, welchem Tag es entspricht.
Bewahren Sie das Artefakt Byte für Byte auf. Eine spätere Neugenerierung führt möglicherweise nicht zu identischen Bytes, da Archivformate Zeitstempel und Reihenfolgen speichern.

Dieser letzte Punkt überrascht viele. Ein tar.gz, das vom selben Tag auf einer anderen Maschine neu erstellt wird, ist häufig eine andere Datei. Bewahren Sie diejenige auf, die Sie gehasht haben.

Reproduzierbarkeit herstellen, falls Sie Schritt 5 überspringen möchten

Deterministische Archive sind mit Aufwand erreichbar — feste Änderungszeiten, sortierte Einträge, ein festgelegter Komprimierungsgrad. Wenn Ihr Build bereits reproduzierbar ist, bedeutet das Hashen der Ausgabe, dass jeder sie unabhängig neu generieren und prüfen kann, was stärker ist, als andere darum zu bitten, Ihre gespeicherte Kopie zu vertrauen.

Wenn dies nicht der Fall ist, ist das Aufbewahren des Artefakts völlig vernünftig und viel günstiger, als den Build allein zu diesem Zweck deterministisch zu machen.

Was Ihnen das bringt

Frage	Beantwortet durch
Was haben wir ausgeliefert?	Das Artefakt
Wann haben wir es ausgeliefert?	Der Zeitstempel
Wer hat es geschrieben?	Signierte Commits und Tags
Hat es sich seither geändert?	Der Zeitstempel
Ist es authentisch?	Ein signiertes Tag plus der Zeitstempel

Signierung und Zeitstempelsetzung ergänzen sich gut und beantworten unterschiedliche Fragen. Ein signiertes Tag beweist, wer es erstellt hat, und dass die Inhalte unverändert sind; das Datum der Signatur ist jedoch weiterhin das, was die Maschine des Unterzeichners behauptet hat. Die Zeitstempelsetzung fixiert die Zeit unabhängig davon. Machen Sie beides für relevante Releases.

Wann es sich lohnt

Öffentliche Releases, bei denen das Datum in Lizenz- oder Verletzungfragen relevant sein könnte.

Vor einem Audit, einer Treuhandeinlage oder einer Akquisition — ein datiertes Protokoll dessen, was genau übergeben wurde.

Vor der Offenlegung von Code an einen Kunden oder Partner, was auch der Moment ist, in dem der Code am stärksten als Geschäftsgeheimnis exponiert ist. Siehe Markenschutz vs. Urheberrecht für Quellcode.

Wenn Sie eine permissive Lizenz verwenden und ein Protokoll Ihres Versionsstandes vor den Ansprüchen eines Forks wünschen.

Es lohnt sich nicht für jeden Commit. Der Punkt liegt in einer kleinen Anzahl datierter Ankerpunkte um Zustände, die verteidigt werden müssen, nicht in Zeremonien bei der normalen Arbeit.

Für die weiter gefasste Version dieses Arguments siehe Blockchain-Zeitstempel für Softwareteams.

Wie Sie einen Software-Release mit einem Zeitstempel versehen