Die geplante Veröffentlichung von Git 3.0 sieht eine fundamentale Änderung des Standards für Hashing-Algorithmen vor. Die Versionsverwaltung soll künftig von SHA-1 auf SHA-256 umgestellt werden.
Während dieser Schritt die langfristige Sicherheit gewährleisten soll, warnen Experten vor erheblichen Verwerfungen innerhalb des Software-Ökosystems. Scott Chacon, Mitbegründer von GitHub, bezeichnete das Vorhaben als einen unvorstellbar teuren und letztlich wertlosen sowie vermeidbaren globalen Albtraum.
Technische Hürden und drohende Inkompatibilitäten
Die Umstellung bringt tiefgreifende technische Herausforderungen mit sich. Repositories, die unterschiedliche Hash-Algorithmen nutzen, können nicht ohne Weiteres zusammenarbeiten. Insbesondere bei Submodulen wird ein übereinstimmendes Format zur Voraussetzung für die Funktionalität.
Zudem müssen sämtliche Entwicklungswerkzeuge angepasst werden, um die längeren 64-Zeichen-Hashes von SHA-256 anstelle der bisherigen 40-Zeichen-Hashes von SHA-1 verarbeiten zu können.
Fachleute warnen vor verschiedenen Risiken während und nach der Migration. Dazu gehören Inkompatibilitäten zwischen verschiedenen Hosting-Plattformen (Forges), Brüche in bestehenden Tool-Ketten sowie die Ungültigmachung digitaler Signaturen.
Ein weiteres Problem stellt der sogenannte „Link-Rot“ dar, bei dem bestehende Verweise auf spezifische Commits durch die geänderten Hash-Werte ihre Gültigkeit verlieren könnten. Erste Tests der neuen Struktur sind bereits über spezielle Befehle möglich, mit denen Repositories im SHA-256-Format initialisiert werden können.
Die Debatte um die Sicherheit von SHA-1
SHA-1 ist seit dem Jahr 2005 fester Bestandteil von Git. In den vergangenen zwei Jahrzehnten wurden keine Fälle dokumentiert, in denen es zu versehentlichen SHA-1-Kollisionen innerhalb von Git-Repositories kam. Die statistische Wahrscheinlichkeit für eine solche Kollision wird erst bei einer Menge von rund 1,4 Septillionen Dateien kritisch.
Dennoch gilt der Algorithmus seit Forschungsergebnissen aus den Jahren 2017 und 2020 als theoretisch gebrochen. Ein gezielter Kollisionsangriff ist heute mit einem finanziellen Aufwand von einigen Zehntausend US-Dollar für Rechenleistung realisierbar.
Die geplante Umstellung von SHA-1 auf SHA-256 in Git 3.0 verlangt von jedem Repo und jeder Tool-Kette Anpassungen — von 40 auf 64 Zeichen. Wer jetzt prüft, welche Werkzeuge betroffen sind, vermeidet Brüche in CI-Pipelines und Submodulen. Kostenlosen Migrations-Leitfaden anfordern
Kritiker der Umstellung, wie Scott Chacon, geben jedoch zu bedenken, dass für einen erfolgreichen Kollisionsangriff der Angreifer die Kontrolle über die Erstellung der Originaldatei haben müsse. Reale Bedrohungen für die Lieferkette, wie etwa die Kompromittierung von Maintainer-Accounts bei Paketmanagern oder das sogenannte Typosquatting, seien deutlich kostengünstiger und damit wahrscheinlicher.
Bereits bei der Einführung von Git im Jahr 2005 betonte Linus Torvalds, dass die eigentliche Sicherheit des Systems in seiner verteilten Natur liege. Während Brute-Force-Angriffe auf moderne Verfahren selbst mit massiver Rechenleistung Milliarden von Jahren dauern würden, bleibt die Frage nach der praktischen Relevanz für den Entwickleralltag umstritten.
Zeitplan und Unterstützung in der Industrie
Trotz der Kritik drängt die Standardisierung auf modernere Verfahren. Die US-Behörde NIST hat eine Frist bis zum Jahr 2030 für die Abkehr von veralteten Algorithmen gesetzt. Die großen Plattformen reagieren unterschiedlich schnell auf diese Anforderungen.
Während GitLab bereits seit etwa einem Jahr Unterstützung für SHA-256 bietet, befindet sich GitHub derzeit in einer privaten Testphase. Eine allgemeine Verfügbarkeit bei GitHub wird in den kommenden Monaten erwartet.
Die Veröffentlichung von Git 3.0 ist nach aktuellem Stand für das Frühjahr 2027 geplant. In diesem Kontext wird auch über administrative Lösungen nachgedacht. So berichtete Emily Shaffer, dass Google systemweite Überschreibungen für SHA-1 in Erwägung ziehe, um Sicherheitsvorgaben umzusetzen.
Performante Alternativen und Implementierungsansätze
Abseits der direkten Umstellung des Kern-Algorithmus existieren alternative Ansätze zur Absicherung von Code-Historien. Das bereits seit 2015 bestehende Projekt git-evtag von Colin Walters nutzt beispielsweise unabhängige SHA-256- oder BLAKE3-Header für Tree-Hashes.
Bestehende Verweise auf Commits, digitale Signaturen und Submodul-Formate können durch die geplante Hash-Umstellung ihre Gültigkeit verlieren. Dieser Leitfaden zeigt, wie Sie Link-Rot und Signatur-Invalidierung frühzeitig erkennen und Ihre Repos absichern. Leitfaden zur Hash-Umstellung jetzt sichern
Dass moderne kryptografische Prüfungen nicht zwangsläufig zu Performance-Einbußen führen müssen, zeigen aktuelle Messwerte. Die Überprüfung des Linux-Kernels beansprucht lediglich 257 Millisekunden.
Selbst bei extrem umfangreichen Projekten wie Chromium, das mit 2,1 Millionen Dateien einen Umfang von 35 Gigabyte erreicht, dauert der Vorgang auf moderner Hardware nur etwa fünf Sekunden. Diese Werte verdeutlichen, dass die Rechenleistung für den Wechsel vorhanden ist, die logistischen Herausforderungen der globalen Migration jedoch die eigentliche Hürde darstellen.
