Git als beweisfestes Langzeitarchiv(?)

11.01.2023

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.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Aviator + Websockets

    15.06.2019

    Nachdem ich in den letzten Wochen und Monaten meine Zeit und Energie in die sQLshell gesteckt habe - was sowohl Bugfixing als auch neue Features betraf - habe ich nun endlich die Zeit gefunden, ein bereits lange überfälliges Feature an dWb+ und speziell am aviator zu implementieren.

    Weiterlesen...

Neueste Artikel

  • Neue Version plantumlinterfaceproxy napkin look

    Es gibt eine neue Version des Projektes plantumlinterfaceproxy - Codename napkin look.

    Weiterlesen...
  • Apache HTTPCore5 funktioniert nicht mit Docker

    Ich habe neulich drei Stunden meines Lebens verschwendet weil ich unbedingt die neueste Version der HTTPCore5 Library von Apache einsetzen wollte.

    Weiterlesen...
  • Entwurfsmodus für beliebige SVG Graphiken

    Nachdem ich in der Vergangenheit immer wieder Weiterentwicklungen der Idee vorgestellt habe, Graphiken mit dem Computer so zu ezeugen dass sie eine gewisse "handgemachte" Anmutung haben, habe ich nunmehr die durchschlagende Idee gehabt:

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.