# Versionsnummern bei GIT



## davido (7. Jun 2017)

Hallo zusammen,

ich habe neulich gelesen, dass GIT den Hashwert SHA-1 für die Versionsnummern benutzt.
Mittlerweile ist ja bekannt, dass SHA-1 nicht mehr sicher ist.
Warum verwendet GIT nicht Hashwerte wie SHA-256 oder SHA-512 für die Versionsnummern?
Vielen Dank schon einmal für eure Antworten.

VG

Davido


----------



## tommysenf (7. Jun 2017)

Weil die Generierung der Versionsnummern keinen Sicherheitsanforderungen erfüllt. Eine aufwendige Hashberechnung wären daher verschwendete Ressourcen.


----------



## mrBrown (7. Jun 2017)

Damals reichte SHA-1, und im Nachhinein ist zu komplex und würde vermutlich nicht abwärtskompatibel sein, daher wird es erstmal dabei bleiben, der Aufwand der Berechnung spielt dabei vermutlich nur ne ziemliche kleine Rolle


----------



## Tobse (7. Jun 2017)

SHA-1 reicht auch heute noch: wie @tommysenf sagte: der Versions-Hash in Git ist in keiner Weise Sicherheitsrelevant. Er dient dazu, einem Commit, der beliebig groß sein kann, einen eindeutigen und kleinen Identifier zuzuordnen. Dafür ist SHA-1 nach wie vor wunderbar geeignet. Kollisionen kann man zwar provozieren, bei Git versucht das aber niemand; wenn ein Angreiffer Commits in ein Repository pushen kann hat schon eine viel wichtigere Sicherheitsfunktion versagt.
Bei den 160 Bits, die SHA-1 ausgiebt, ist eine Kollision statistisch nach 2^80 Commits zu erwarten. 2^80 = 1,208 * 10^24 = 1.208.000.000.000.000.000.000.000 Das erreicht kein Repository. Zum vergleich:

1. In den Projekten bei meinem aktuellen Arbeitgeber produzieren wir bei Vollzeit-Arbeit im Schnitt 70 Commits pro Monat und Person. Bei dieser Geschwindigkeit müssten wir in einem Team mit 50 Leuten (und das ist für uns lächerlich viel, 5-10 ist realistisch) 2,9 * 10¹⁹ Jahre an dem Projekt arbeiten, bis zwei Commits mit dem selben Hash zu erwarten sind. Der Urknall ist 1,38 * 10⁸ Jahre her.

2. Das größte Git Repository, was ich auf die schnelle finden konnte, generiert ~ 62.000 commits im Monat, also c.a. 10⁶ commits im Jahr. Selbst dieses Projekt muss zwei Commits mit dem selben Hash erst nach 1,2*10¹⁸ Jahren erwarten.

---

Ein größeres Problem ist die kürzung des Hashes auf 7 Stellen an den meisten Stellen. Mit 7 Stellen gibt es nämlich nur ~ 2,6 * 10⁸ Kombinationen; eine Kollision ist nach 1,3 * 10⁸ commits zu erwarten. Das riesige Git-Repo, welches ich oben nannte, kann damit nach 13 Jahren einen Commit nicht mehr mit den ersten 7 Stellen des Hashes eindeutig identifizieren. Aber 13 Jahre lang 1 Millionen commits / Jahr durchhalten? Unwahrscheinlich.

Fazit: SHA-1 wird seinen Zweck in Git noch seeeeeehr lange mehr als gut genug erfüllen.


----------

