Git 3.0s SHA-256-Standard ist ein teurer Fehler, sagt Chacon

Scott Chacon sagt, Gits Plan, SHA-256 in Version 3.0 zum Standard-Hash für neue Repositories zu machen, werde ein teurer Fehler. Sein Argument, am 30. September 2026 im GitButler-Blog veröffentlicht, kommt zu einem Zeitpunkt, an dem das Git-Projekt selbst sagt, der Wechsel warte, bis das breitere Ökosystem bereit ist. Der Streit ist wichtig, weil jedes Werkzeug, das eine Git-Commit-ID speichert oder auswertet, von der Antwort betroffen ist.

Tech AI Wire hat den Git-3.0-Plan im September beschrieben. Neue Repositories bekommen SHA-256-Objektnamen, das Reftable-Format und einen main-Branch, und zum Bauen von Git wird Rust nötig.

Was Chacon argumentiert

Git identifiziert jede Datei, jeden Ordner und jeden Commit über einen Hash, einen Fingerabdruck fester Länge, der aus dem Inhalt berechnet wird. Git nutzt dafür von Anfang an den Algorithmus SHA-1. SHA-1 gilt als schwach. Mit genug Aufwand können Forscher zwei verschiedene Eingaben mit demselben Fingerabdruck erzeugen, was man eine Kollision nennt.

Chacons These lautet, dass diese Schwäche für Git theoretisch ist. In Milliarden von Git-Repositories sei keine Kollision dokumentiert worden, schreibt er, trotz der bekannten mathematischen Schwächen von SHA-1.

Dann zählt er die Kosten auf. Ein SHA-256-Repository bricht jeden bestehenden SHA-1-Hash. URLs, Commit-Verweise in Bugtrackern und alles andere, was eine 40-Zeichen-ID zitiert, passt nicht mehr. Die meisten Git-Bibliotheken, sagt er, unterstützen SHA-256 nicht vollständig.

Seine Alternative ist, die Integrität zu prüfen, ohne die Objektnamen zu ändern. Chacon berichtet, dass das Hashen eines kompletten ausgecheckten Baums schnell geht. Seine Tests brauchten etwa 5 Sekunden für den 35 GB großen Chromium-Baum mit 2,1 Millionen Dateien und 257 Millisekunden für den 1,5 GB großen Linux-Kernel. Er schlägt vor, SHA-256-Prüfsummen in signierte Objekte neben die SHA-1-Namen einzubetten. Ein Projekt könnte dann mit dem stärkeren Hash prüfen, ohne das Ökosystem zu spalten. Als Vorbild für die Idee nennt er git-evtag, ein Werkzeug aus dem Jahr 2015.

Was das Git-Projekt sagt

Gits eigenes Dokument zu Breaking Changes beschreibt den Plan, gegen den Chacon argumentiert. Git 3.0 ändert den Standard-Hash nur für neu angelegte Repositories auf SHA-256. Bestehende SHA-1-Repositories arbeiten weiter, und laut dem Dokument gibt es keinen Plan, das SHA-1-Objektformat abzukündigen.

Das Dokument erklärt auch, warum das Projekt die Änderung will. Es nennt SHA-1 kryptografisch gebrochen und listet die Belege auf.

Meilenstein	Jahr
NIST stuft SHA-1 als veraltet ein	2011
SHAppening-Angriff	2015
SHAttered-Kollision	2017
Git wählt SHA-256 als Nachfolger	Ende 2018
Birthday-Near-Collision-Angriff	2019
Shambles-Angriff	2020

Zwei Punkte im Dokument sprechen für Chacon. Das Git-Projekt sagt, es werde die Änderung erst vornehmen, wenn Bibliotheken, Hosting-Plattformen und Drittanwendungen zeigen, dass sie für SHA-256 bereit sind. Und es nennt kein Veröffentlichungsdatum für Git 3.0. Frühere Berichte hatten die Veröffentlichung auf etwa Ende 2026 gelegt; das Dokument selbst nennt kein Datum.

Wie der Übergang gedacht ist

Gits Design zum Hash-Funktions-Übergang zeigt, dass das Projekt über Interoperabilität nachgedacht hat. Die Wahl von SHA-256 geht auf Ende 2018 zurück. Das Design lässt jedes Repository in seinem eigenen Tempo wechseln. Ein SHA-256-Repository führt eine Übersetzungstabelle in beide Richtungen, sodass ein Objekt während des Übergangs über beide Hashes ansprechbar ist.

Auch Netzwerkoperationen sind abgedeckt. Das Design beschreibt Push und Fetch zwischen SHA-256- und SHA-1-Servern, wobei Objekte beim Packen umgewandelt werden. Commits können zwei Signaturen tragen, eine im bestehenden Feld gpgsig und eine in einem neuen Feld gpgsig-sha256. Die Arbeit ist in fünf Phasen aufgeteilt und endet mit dem vollständigen Übergang, sobald genug Repositories gewechselt haben. Zwei Grenzen bleiben: Shallow Clones und Alternates funktionieren nicht zwischen SHA-1- und SHA-256-Repositories.

Der sichtbare Unterschied ist die Länge. Ein SHA-1-Objektname hat 40 Hexadezimalzeichen. Ein SHA-256-Name hat 64.

Was das für Entwickler bedeutet

Für Sie ändert sich heute nichts. Git 3.0 hat kein Veröffentlichungsdatum, und bestehende Repositories bleiben so oder so bei SHA-1. Die Frage ist, was Sie tun sollten, bevor ein neuer Standard kommt, wann immer das ist.

Erstens: Testen Sie Ihre Werkzeuge jetzt gegen ein SHA-256-Repository. Chacons Behauptung, die meisten Git-Bibliotheken unterstützten es nicht vollständig, lässt sich prüfen. Legen Sie ein Test-Repository im SHA-256-Modus an und lassen Sie Ihre CI-Skripte, Deployment-Hooks und Code-Review-Integrationen dagegen laufen.

Zweitens: Prüfen Sie alles, was eine 40-Zeichen-ID voraussetzt. Datenbankspalten, reguläre Ausdrücke und URL-Muster, die diese Länge fest verdrahten, werden 64-Zeichen-Namen abschneiden oder ablehnen. Unser Artikel vom September hat denselben Punkt gemacht. Chacons Beitrag erinnert daran, dass der Bruch jeden gespeicherten Link erfasst.

Drittens: Wägen Sie seine Alternative nach ihrem Wert ab. Wenn es Ihnen um Manipulationserkennung statt um Benennung geht, liefern signierte Prüfsummen über den Baum das schon heute, ohne Formatwechsel. Wenn Sie SHA-256-Objektnamen brauchen, unterstützt das Übergangsdesign bereits den Wechsel pro Repository mit SHA-1-Interoperabilität. Sie müssen nicht auf 3.0 warten.

Und schließlich: Achten Sie auf den Bereitschaftstest des Projekts statt auf die Versionsnummer. Das Dokument zu Breaking Changes knüpft den Standardwechsel an die Bereitschaft des Ökosystems. Das heißt, Forges und Bibliotheken entscheiden, wann es passiert, nicht der Git-Release-Kalender.