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.
Testdatengeneratoren als Microservices mit Docker
02.11.2019
Ich habe die verschiedenen Testdatengeneratoren mittels Microservices über HTTP zugänglich gemacht, um sie unabhängig von der verwendeten Programmiersprache und/ oder Version (Java 11) verwenden zu können.
Weiterlesen...Android Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Git(lab|hub) Go GUI Gui Hardware Java Jupyter Komponenten Links Linux Markdown Markup Music Numerik PKI-X.509-CA Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
Nachdem es nun bereits seit einiger Zeit ein wenig stiller um meine diversen Generatoren für Testdaten geworden ist, habe ich über den Feiertag in Thüringen einen neuen begonnen.
Weiterlesen...Ich wurde über einen Post auf Mastodon auf ein Projekt aufmerksam, das mir so interessant erschien, dass ich daraus meine neueste Fingerübung machte...
Weiterlesen...Eine neue Version der sQLshell ist verfügbar!
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.