Ruta de desarrollo de confianza en git con firmas

Question

Me gustaría construir una ruta confiable para el desarrollo de software. Esto significa que cada cambio en el código debe estar firmado por el autor y un revisor, antes de ser aceptado. Estas firmas para los cambios deben ser verificables en el momento de la liberación, o debe haber algún otro otro medio para asegurarse de que el repositorio no haya sido manipulado , o se hayan agregado cambios adicionales.

El sistema de control de versiones que espero usar para esto es git, pero también se aceptan otras opciones. La firma puede hacerse a través de GnuPG o certificados SSL.

El flujo de trabajo Pienso que sería más o menos:

1. actual tronco verificado es ramificado
2. Los cambios se desarrollan en la rama por uno o más desarrolladores
3. Uno o más desarrolladores firmar los cambios realizados por la rama
4. A opiniones revisor y prueba los cambios
5. Crítico firma los cambios realizados por la rama
6. Branch se "fusionó" para el tronco verificado actual

La fusión no tiene que ser a prueba de tontos como que no revisadas cambios tendría que ser fusionables al tronco - sólo que antes de un comunicado, es necesario que haya una forma de comprobar si hay cambios no revisados ​​(sin firmar) en el enlace troncal. Y, en general, no es necesario prevenir la manipulación, solo detectarla.

Me gustaría obtener una breve guía sobre cómo configurar esto y cómo se realiza cada operación. Una vez que obtengo algunos consejos, puedo averiguar los detalles yo mismo.

Además, ya sé sobre 'git tag -s' técnicamente, pero no estoy seguro de cómo aplicarlo a este problema en particular.

Answer 1

Los cambios no se firmarán hasta que marque. Cualquier cosa anterior a ese punto puede ser verificada por el autor o por otro mecanismo fuera de banda, pero no desde dentro de git.

git puede verificar que el patrimonio de un cambio es correcto, pero solo la etiqueta firmada puede verificar que el cambio en sí sea correcto.

Para su flujo de trabajo, es posible que se encuentre etiquetando mucho.

Answer 2

Git es un buen candidato desde:

• cada uno se dedica ya están firmados
• la clave SHA1 para cada confirmación es suficiente para asegurarse de que la cesión temporal todo no se ha modificado
• git tag -s se puede utilizar para firmar un compromiso a alguien no hizo (git tag -m is more explicit)

Así:

1. tronco verificado actual es ramificado

   git checkout -b tag_for_last_verified_trunk_content test # branch test

2. Los cambios se desarrollan en la rama por uno o más desarrolladores

   [work...] git commit -s -m "dev1 comment" ...

3. Uno o más desarrolladores firmar los cambios realizados por la rama

   Ya hecho con sus confirmaciones, agregando una línea Firmada al final del mensaje de confirmación: vea esta página para explanation on the signed-off proceso.

   Signed-off-by: user name

4. A opiniones revisor y pruebas de los cambios

    git tag -m "testing" testing # refer to current commit, 
              allowing dev to go on with further changes

5. Crítico firma los cambios realizados por la rama

   git tag -m "tested" tested testing # put a tag on the same SHA1 than 
               the "testing" tag

6. Branch se "fusionó" para el tronco verificado actual

   git checkout trunk & git merge tested

---

Cyryl Plotnicki-Chudyk menciona in the comments que, desde Git 1.7.9 (enero de 2012, casi 2 años después de esta respuesta), puede GPG-firmar ningún commit desea, usando git commit -S.
(Ver commit ba3c69a9, refinado, más recientemente, en commit df45cb3)

Answer 3

Puede firmar su etiqueta con su clave GPG con la opción -s en la etiqueta git tag -s v0.1.0:

-s

Make a GPG-signed tag, using the default e-mail address's key 

Pero no puedes firmar un compromiso.