when - release tag git

¿Cómo puedo usar las marcas de tiempo RFC3161(de confianza) para demostrar la edad de las confirmaciones en mi repositorio Git? (4)

Actualizado

He publicado un script que estoy usando para esto en el sitio de Revisión de Código de StackExchange.

Mi pregunta original para esto fue: ¿Hay alguna manera de firmar un compromiso Git con un certificado X.509 y una marca de tiempo? . Por un tiempo pensé que solo podía obtener las cosas que firmé con un certificado X.509 marcado por un tercero de confianza. Este no es el caso. La firma digital con un certificado X.509 y la marca de tiempo de confianza son mutuamente excluyentes. He actualizado mi pregunta para reflejar esto.

Como lo señaló VonC, la firma de confirmaciones de Git con un certificado X.509 no agrega ningún valor. El uso de una llave GPG es una opción mucho mejor debido a la compatibilidad incorporada de Git.

He aceptado la respuesta de Greg porque es lo más cercano a lo que estaba pidiendo, aunque mi pregunta original era un poco ambigua. Como lo señala Greg, si puede probar que conoció un hash de confirmación en un determinado momento, eso garantiza que sabía el contenido del repositorio para el que se trata en ese momento y no hay necesidad de almacenar datos adicionales en el repositorio. Los datos de la marca de tiempo se pueden almacenar en cualquier lugar.

Es posible usar openssl (v1.0.0 +) y curl para solicitar marcas de tiempo RFC3161 para hashes de confirmación.

Solicitar una marca de tiempo

Necesitarás tener un poco de información para esto:

URL: un servicio de sellado de tiempo RFC3161
REV - La revisión (hash) para la que desea una marca de tiempo. Debe ser un hash completo.

CONTENT_TYPE="Content-Type: application/timestamp-query" ACCEPT_TYPE="Accept: application/timestamp-reply" openssl ts -query -cert -digest "$REV" -sha1 / | curl -s -H "$CONTENT_TYPE" -H "$ACCEPT_TYPE" --data-binary @- $URL

Lo anterior dará salida a la marca de tiempo firmada a la salida stdout . También puede generar un error si el servicio de marca de tiempo rechaza la solicitud.

Verificar una marca de tiempo

Esto es muy similar a solicitar una marca de tiempo, pero también necesita:

CAFILE: una cadena de certificados desde el servicio de marca de tiempo hasta una CA raíz

El servicio de sellado de tiempo debe estar firmando las marcas de tiempo con un certificado emitido por una autoridad de confianza. Si no, sus marcas de tiempo no tienen mucha credibilidad. Si no puede encontrar o crear una cadena de certificados adecuada, intente usar el cacert.pem publicado por curl . Esta here

El siguiente fragmento de código supone que se está pasando una respuesta de marca de tiempo firmada existente a stdin . Debería ser posible canalizar la solicitud anterior directamente en el siguiente comando de verificación. Si almacena la respuesta de la solicitud en una variable, puede ser necesario codificar / decodificar en man base64 ( man base64 ).

openssl ts -verify -digest "$REV" -in /dev/stdin -CAfile "$CAFILE"

Si examina una respuesta, notará que el resumen de la solicitud coincide con la revisión de Git que se utilizó. Puede examinar una versión de texto sin formato de una respuesta con este comando.

openssl ts -reply -in /dev/stdin -text

Aquí hay un ejemplo de una respuesta donde agregué la revisión de Git en la parte superior.

-------------------------------------------------------------------------------- Revision: 871d715e5c072b1fbfacecc986f678214fa0b585 -------------------------------------------------------------------------------- Status info: Status: Granted. Status description: unspecified Failure info: unspecified TST info: Version: 1 Policy OID: 1.3.6.1.4.1.6449.2.1.1 Hash Algorithm: sha1 Message data: 0000 - 87 1d 71 5e 5c 07 2b 1f-bf ac ec c9 86 f6 78 21 ..q^/.+.......x! 0010 - 4f a0 b5 85 O... Serial number: 0xB2EA9485C1AFF55C6FFEDC0491F257C8393DB5DC Time stamp: Aug 15 08:41:48 2012 GMT Accuracy: unspecified Ordering: no Nonce: 0x615F0BF6FCBBFE23 TSA: DirName:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Time Stamping Signer Extensions:

Otras notas

Una gran cantidad de servicios de sellado de tiempo piden a los usuarios que agreguen un retraso a las solicitudes de firma con script. Asegúrese de averiguar si el servicio que planea usar lo requiere. En el momento de escribir el que estoy usando, Comodo, solicita un retraso de 15 segundos entre las solicitudes de script. La única razón por la que elegí usar Comodo es porque de ahí compré mi certificado de firma de código.

Las notas de Git parecen ser la opción obvia para almacenar respuestas de marca de tiempo firmadas, pero no tengo una solución completa para publicar. Estoy atascado en this en this momento.

Mi pregunta original y actualizaciones están abajo.

Me gustaría poder probar cuándo están ocurriendo mis confirmaciones de Git y que la historia de mi repositorio no ha sido reescrita. No tiene que ser todo compromiso. Una vez al día o una vez a la semana sería suficiente. ¿Hay alguna forma recomendada de hacerlo?

Sé que puedo firmar las confirmaciones de Git con una clave GPG, pero me pregunto si hay una manera de firmar mis confirmaciones con un certificado X.509 y el uso de un servicio de sellado de tiempo en línea como http://timestamp.comodoca.com/rfc3161 .

De lo contrario, ¿descartar la revisión actual utilizando git rev-parse --verify HEAD en un archivo de texto una vez al día, firmando ese archivo y confirmando sería suficiente para probar (aproximadamente) cuándo se escribió mi código?

Información añadida para mayor claridad

Sé que Git garantiza la integridad de un repositorio, pero, según tengo entendido, si controlo el repositorio, un tercero tendría que confiar en que no he vuelto a escribir el historial del repositorio o que he revertido mi reloj. ¿Creé un repositorio completamente falso solo para "probar" que mi código es más antiguo de lo que realmente es? Tampoco quiero publicar mi repositorio públicamente.

Aquí hay unos casos de uso ficticios que deberían dar una mejor idea de lo que quiero hacer.

Publico algún código en línea. Un año después, alguien copia y publica el mismo código en un libro o artículo y afirma que yo fui el que los copió. En ese momento, me gustaría poder tomar mi repositorio y probar que cometí ese código hace un año, antes de que lo reeditaran.

Al usar un certificado X.509 con un servicio de sellado de tiempo, puedo probar cuándo ocurrió la firma. Mientras pueda demostrar que conocía el hash para el compromiso de un año, Git garantiza la integridad del archivo.

Alternativamente, ¿hay una manera de firmar un compromiso usando una clave GPG, pero con una marca de tiempo verificada? ¿Existe un tercero de confianza que brinde un servicio de sellado de tiempo similar a los disponibles para los certificados X.509, pero para GPG?

Tal vez podría usar una combinación de una clave GPG y un certificado X.509. Suponiendo que guardo una copia de mi clave GPG (pública) en el repositorio, ¿funcionaría lo siguiente si lo hiciera al final de cada día?

Firme mi clave GPG (pública) con mi certificado X.509 y un servicio de sellado de tiempo en línea.
Confirme el cambio en el repositorio con una firma de mi clave GPG (privada).

Acabo de escribir un programa llamado " GitLock " exactamente para este propósito. Añade marcas de tiempo de confianza a su repositorio.

https://www.npmjs.com/package/gitlock

No lo estoy siguiendo, porque Linus hizo Git con esa característica específica en mente (es decir, la integridad de lo que estás poniendo es exactamente lo que sale)

Ver es el discurso de 2007 en Google ( transcript ):

La mayoría de ellos los podía descartar sin siquiera probarlos.
Si no estás distribuido, no vale la pena usarlo, es así de simple.
Si lo haces mal, no vale la pena usarlo, es así de simple.
Y si no puede garantizar que las cosas que puse en un SCM sean exactamente iguales, no vale la pena usarlas .
Francamente, eso prácticamente se hizo cargo de todo lo que hay por ahí.
Hay una gran cantidad de sistemas SCM que no garantizan que lo que obtienes de nuevo sea lo mismo que pones.
Si tiene una corrupción de memoria, si tiene una corrupción de disco, es posible que nunca lo sepa.
La única forma de saberlo es si observa que hay daños en los archivos cuando los verifica. Y el sistema de gestión de control de fuente no lo protege en absoluto.
Y esto ni siquiera es raro. Es muy muy común. .

Así que no creo que agregar otra característica de integridad agregue ningún valor.
Y la "marca de tiempo" tampoco es una buena idea, ya que no se grabaron para un DVCS en primer lugar (vea " Git: revisar el archivo antiguo CON las marcas de tiempo creadas / modificadas originalmente ", y " ¿Cuál es el equivalente de use-commit-times para git? ")

Simplemente agregue un certificado de marca de tiempo a su último compromiso. Sha1 verificará que el certificado no se haya modificado, y el certificado en sí mismo verificará todos los "hechos" que afirma, como la marca de fecha y hora de un servidor de confianza, y quién dice ser, etc. es decir, la confirmación firma el certificado, según la cita de VonC del discurso de Linus ;-)

[EDITAR] Obviamente, usted necesita publicar el sha1 de ese nuevo compromiso, de lo contrario podría enmendarlo (y el certificado) y usar el nuevo sha1 para reclamar lo que haya en el historial de ese nuevo compromiso. Como siempre está creando la web de confianza mutua.

Todo lo que tienes que hacer es publicar el SHA1 (el ID de confirmación) públicamente. Si lo desea, puede tomar ese SHA1 y firmarlo con su certificado X.509 (usando un servicio de sellado de tiempo apropiado) y mantenerlo. Si alguien desafía su autoría, puede demostrar fácilmente que conocía el contenido del repositorio en el momento en que se generó ese SHA1 en particular. No es necesario que almacene ninguna firma dentro del repositorio de códigos.