Ich habe hier verschiedentlich über das Thema Langzeitarchivierung berichtet - unter anderem habe ich meinen Timestamping-Server nach RFC3161 so erweitert, dass er entsprechende Archivzeitstempel erstellen kann. Und so stolperte ich zwangsweise über Parallelen zwischen Git und Archivsystemen

Es existieren verschiedene ,link https://medium.com/swlh/git-as-cryptographically-tamperproof-file-archive-using-chained-rfc3161-timestamps-ad15836b883=Anleitungen und Addons für Git, die das System um kryptographisch abgesicherte Zeitstempel erweitern (sollen). Allerdings machen all diese Dinge Git nicht zu einem Beweisfesten Langzeitarchiv für Dokumente.

Aber fangen wir vorne an: Zunächst wird in einem echten System zur beweisfesten Langzeitarchivierung ein Hash-Tree aufgebaut, bei dem in die Berechnung des Hashes der Wurzel des Baumes die Hashes der nächsttieferen Ebene eingehen - Die Blätter eines solchen Baumes bilden dann die eigentlichen Dokumente. Die Wurzel des Gesamtbaumes (bzw. deren Hashwert) wird anschließend mittels eines kryptographisch abgesicherten Zeitstempels fixiert.

Nun können zwei Ereignisse auftreten, gegen die ein solches Archiv abgesichert werden muss: Das Hashverfahren zur Berechnung der Werte im Hash-Tree wird unsicher oder das Zertifikat zur Erzeugung des Zeitstempels wird aus irgendeinem Grund als unsicher eingestuft. Der zweite Fall ist der einfachere: man kann einfach einen neuen Zeitstempel durch eine neue TimeStamping Authority (TSA) erzeugen lassen und diesen mit den vorangegangenen zu einem Archivzeitstempel kombinieren. Das ist auch für Git problemlos möglich.

Das erste der genannten Probleme ist im Zusammenhang mit Git weitaus kritischer: Dort wird immer noch SHA-1 eingesetzt, das für Archivierungszwecke bereits seit längerem als unsicher eingestuft wird.

Für Git bedeutet das nicht ein generelles Problem, da es ursprünglich nicht als Archivsystem projektiert war. Es bedeutet aber auch, dass aus diesem Grund von seinem Einsatz als Archivsystem dringend abzuraten ist. Es existieren zwar Bemühungen, Git mit einem anderen Hashverfahren auszustatten, allerdings sind dabei noch jede Menge praktischer Probleme zu lösen...

Um als Archivsystem benutzt werden zu können, müsste es eine praktikable, wohldokumentierte und robuste Methode geben, die Hashes für ein gesamtes Repository auf einen alternativen Algorithmus umzustellen. Dies ist aus meiner Sicht noch nicht gegeben. Ein weiteres Problem während der Migrationsphase zwischen verschiedenen Hash-Algorithmen besteht in der Tatsache, dass Git ein verteiltes Versionsverwaltungssystem ist - so kann es dazu kommen, dass es zu einem bestimmten Zeitpunkt zu einem Unterschied der im Origin- und im lokalen Repo genutzten Algorithmen kommen kann. Pull requests werden so erschwert. Man müsste einen Check einbauen und falls dieser fehlschlägt, dazu zwingen, das lokale Repo ebenfalls upzugraden. Was passiert aber mit early Adoptern, die ihr lokales Repo bereits upgegradet haben, während das Upstream Repo noch mit dem alten Algorithmus arbeitet?

Diese Dinge sind prinzipiell natürlich alle lösbar - auch wenn es etwas Zeit in Anspruch nehmen wird.

Aus meiner Sicht ist aber Git prinzipiell in seiner aktuellen Gestalt nicht als beweisfestes Archivsystem nutzbar: Man kann das gesamte Repo als ein Dokument ansehen und für dieses auch entsprechende Evidence Records mit Archivzeitstempeln erzeugen. Ein Archiv enthält aber viele verschiedene Dokumente - für alle ist jeweils ein Hashwert berechnet und mit diesen und den Hashwerten in den Nachbarknoten lässt sich für jedes einzelne ein entsprechender Evidence Record erstellen. Mir ist derzeit keine Möglichkeit bekannt, Git davon zu überzeugen, diese Informationen auszulesen, um daraus dokument-bezogene Evidence Records zu erstellen. Daher wird Git - wenn überhaupt - immer nur ein beweisfestes Archivsystem sein, das genau ein Dokument - eben das gesamte Repo enthält.

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )