¿El hash de git commit prueba el historial hasta ese momento?

No contra agentes sofisticados con muchos recursos. SHA-1 (el hash usado en git) no se considera criptográficamente seguro en estos días contra los ataques de colisión. Con los métodos publicados para una se estima que la colisión total cuesta alrededor de ~ $ 100,000 en tiempo de cómputo EC2 . Esta es la razón por la que los certificados SSL de SHA-1 se consideran inseguros.

Si ignora la posibilidad de ataques de colisión SHA-1, si le entrega a alguien un hash de confirmación (y luego le otorga acceso al repositorio), puede usar ese hash de confirmación para verificar la siguiente información (que se agrupó en un formato personalizado para crear el hash):

1. el hash sha1 completo del árbol actual (el árbol es esencialmente una lista de archivos de una confirmación con nombres de archivo que apuntan a hashes sha-1 de los datos en archivos)
2. el hash sha1 completo de los compromisos de los padres (múltiple en caso de combinación)
3. El nombre y correo electrónico del autor y del remitente,
4. La marca de tiempo de la confirmación (de acuerdo con la computadora local del usuario)
5. El mensaje de confirmación

Por lo tanto, si envía un correo electrónico a una persona con un hash de confirmación específico 43c5ab273a7c897dfd8cad9cef829b3a657f8491 en un momento determinado, más adelante podrá verificar que la confirmación se realizó apuntando a un árbol específico ( 4c883b33dbb987e46c211f6dad52b91b208661b4 ) con una confirmación principal de cef37643eb57177ac9e4e1f3d0178bc67b381c8e . También se incluirá la marca de tiempo y la información del autor / autor, pero no se debe confiar en que sea precisa. Por ejemplo, cualquier persona puede decirle a su instancia local de git que es el nombre o correo electrónico que desee y enviarlo a un repositorio de bitbucket que controlan.

Tenga en cuenta que, si alguien quiere verificar que tuvo un repositorio de cierta manera el mes pasado, puede volver fácilmente y editar el historial y crear un nuevo commit (con un nuevo hash) que muestra que tuvo el repositorio de esa manera en ese momento. Sin embargo, si les hubiera asignado un hash para confirmar el estado del repositorio en ese momento, esto no sería posible (sin pasar por el problema de generar colisiones de hash).

Como explica el Dr. jimbob, git por defecto no es tan seguro como probablemente le gustaría para esta aplicación. Sin embargo, hay una opción para este tipo de situación, que es firmar sus compromisos o etiquetas con GPG .

Si haces esto, tienen una garantía potencialmente mucho más sólida de que eres el autor de este trabajo; ahora confías principalmente en GPG y la web de confianza para realizar la verificación, en lugar de git. Se aplican las cosas habituales de GPG, por ejemplo, necesitan confiar en su clave, usted necesita mantener su clave segura, etc.

También tenga en cuenta que si firma una confirmación en particular, está verificando la autenticidad de todo el historial de confirmación que lleva a esa. En su caso, esto no debería ser un problema, ya que usted es el único remitente al repositorio, pero es algo que debe tener en cuenta mientras trabaja.

Este puede todavía le proporciona problemas para probar el tiempo . Esa información se almacena en una confirmación, pero puede controlarla (lo más obvio es a través de la modificación del reloj de su sistema). Entonces, lo que tenemos al final de esto es una buena garantía de que confirmó algún texto en particular en lo que afirma que es un momento determinado . Si desea una garantía de que no ha publicado datos con fecha posterior, deberá incluir un sistema externo que tenga un reloj confiable.