Permettez-moi d'explorer pourquoi c'est un problème difficile en utilisant les internes de git. Vous pouvez obtenir le sha1 du commit actuel par
#!/bin/bash
commit=$(git cat-file commit HEAD) #
sha1=($((printf "commit %s\0" $(echo "$commit" | wc -c); echo "$commit") | sha1sum))
echo ${sha1[0]}
Essentiellement, vous exécutez une somme de contrôle sha1 sur le message renvoyé par git cat-file commit HEAD
. Deux choses apparaissent immédiatement comme un problème lorsque vous examinez ce message. L'un est l'arbre sha1 et le second est l'heure de validation.
Désormais, le temps de validation est facilement pris en charge en modifiant le message et en devinant combien de temps il faut pour effectuer une validation ou planifier une validation à un moment donné. Le vrai problème est l'arbre sha1, à partir duquel vous pouvez obtenir git ls-tree $(git write-tree) | git mktree
. Essentiellement, vous faites une somme de contrôle sha1 sur le message de ls-tree, qui est une liste de tous les fichiers et leur somme de contrôle sha1.
Par conséquent, votre somme de contrôle sha1 de validation dépend de la somme de contrôle sha1 de votre arbre, qui dépend directement de la somme de contrôle sha1 des fichiers, qui complète le cercle et dépend du commit sha1. Ainsi, vous avez un problème circulaire avec les techniques dont je dispose.
Avec des sommes de contrôle moins sécurisées , il s'est avéré possible d'écrire la somme de contrôle du fichier dans le fichier lui-même par force brute; cependant, je ne connais aucun travail qui ait accompli cette tâche avec sha1. Ce n'est pas impossible, mais presque impossible avec notre compréhension actuelle (mais qui sait peut-être que dans quelques années, ce sera insignifiant). Cependant, cela est encore plus difficile à utiliser par force brute puisque vous devez écrire la somme de contrôle (de validation) d'une somme de contrôle (d'arborescence) d'une somme de contrôle (blob) dans le fichier.