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.
InfluxDB Appender für Log4J 1.x
17.03.2018
Nachdem ich vor einiger Zeit zwei Appender für Log4J 1.x vorgestellt habe, habe ich - motiviert durch meine Experimente mit Raspi und ADS-B - einen weiteren verfasst - diesmal zum Schreiben der Daten in eine Zeitreihendatenbank.
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...
Ich habe mich ein wenig mit Attribut-Zertifikaten beschäftigt - Resultat sind einige Klassen zum leichteren Zugriff auf die enthaltenen Attribute...
Weiterlesen...Ich wollte eine Methode schaffen, neue Graphik-Primitiven, die zumindest in java.awt.Graphics2D - in Java noch fehlen, zu ergänzen.
Weiterlesen...Ich wollte eine Methode schaffen, unterschiedlichste Schraffuren in beliebigen Shapes zu erzeugen. diese Möglichkeit fehlt - zumindest in java.awt.Graphics2D - in Java noch.
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.