J'ai récemment trouvé une publication du 29/04/2013 dans un groupe de discussion BSD à
http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html
où l'affiche prétend:
J'ai rencontré une fois une collision de hachage, en utilisant git rebase.
Malheureusement, il ne fournit aucune preuve de sa réclamation. Mais peut-être que vous aimeriez essayer de le contacter et lui poser des questions sur ce supposé incident.
Mais à un niveau plus général, en raison de l'attaque d'anniversaire, une chance de collision de hachage SHA-1 est de 1 en pow (2, 80).
Cela semble beaucoup et est certainement bien plus que le nombre total de versions de fichiers individuels présents dans tous les référentiels Git du monde combinés.
Cependant, cela ne s'applique qu'aux versions qui restent réellement dans l'historique des versions.
Si un développeur compte beaucoup sur le rebasage, chaque fois qu'un rebase est exécuté pour une branche, tous les commits de toutes les versions de cette branche (ou partie rebasée de la branche) reçoivent de nouveaux hachages. La même chose est vraie pour chaque fichier modifié avec "git filter-branch". Par conséquent, "rebase" et "filter-branch" peuvent être de gros multiplicateurs pour le nombre de hachages générés au fil du temps, même si tous ne sont pas réellement conservés: Fréquemment, après rebasage (en particulier dans le but de "nettoyer" une branche ), la branche d'origine est jetée.
Mais si la collision se produit pendant le rebase ou la branche de filtre, elle peut encore avoir des effets néfastes.
Une autre chose serait d'estimer le nombre total d'entités hachées dans les référentiels git et de voir à quelle distance elles sont de pow (2, 80).
Disons que nous avons environ 8 milliards de personnes, et toutes utiliseraient git et conserveraient leurs versions dans 100 dépôts git par personne. Supposons en outre que le référentiel moyen a 100 commits et 10 fichiers, et qu'un seul de ces fichiers change par commit.
Pour chaque révision, nous avons au moins un hachage pour l'objet tree et l'objet commit lui-même. Avec le fichier modifié, nous avons 3 hachages par révision, et donc 300 hachages par référentiel.
Pour 100 dépôts de 8 milliards de personnes, cela donne du pow (2, 47) qui est encore loin d'être du pow (2, 80).
Cependant, cela n'inclut pas l'effet multiplicateur supposé mentionné ci-dessus, car je ne sais pas comment l'inclure dans cette estimation. Cela pourrait peut-être augmenter considérablement les chances de collision. Surtout si de très grands référentiels qui ont une longue histoire de commit (comme le noyau Linux) sont rebasés par de nombreuses personnes pour de petits changements, qui créent néanmoins des hachages différents pour tous les commits affectés.
I've been informed by the git Gods that the chances of a SHA1 collision is the same as the Earth being sucked up into the black hole created by the CERN accelerator. If this is indeed true, then there's no need for that extra memcmp.
, source: lwn.net/Articles/307281