¿Por qué debería usar Git commit signing?

Tenemos una request para realizar la firma de compromiso . Después de estudiar el process, no está claro para mí qué problema resuelve firmar firmando. Según entiendo el process, existe un "código fuente local" que se compromete con un "repository local" que se envía a un "repository remoto" . De modo que hay tres cuadros y dos flechas que crean un gráfico dirigido desde los files de origen locales al repository remoto. Para el usuario final, los flujos se invierten.

En el model tal como se describe, parece que queremos que las autorizaciones se produzcan al momento del repository remoto; y los fichajes de compromiso casi no tienen ningún beneficio.

El manual de Git SCM, 7.4 Herramientas de Git – Firma de su trabajo no indica el problema que está resolviendo. sin embargo, me dice que busque la respuesta:

Todos deben firmar

Firmar tags y confirmaciones es excelente, pero si decide usar esto en su flujo de trabajo normal, deberá asegurarse de que todos en su equipo comprendan cómo hacerlo. Si no lo hace, terminará pasando mucho time ayudando a las personas a encontrar la manera de reescribir sus confirmaciones con las versiones firmadas. Asegúrese de comprender GPG y los beneficios de firmar cosas antes de adoptar esto como parte de su flujo de trabajo estándar.

Supongo que los ingenieros de Git han modelado los flujos de trabajo de Git. Identificaron un problema (o problemas) y colocaron el control de security "commit signing" para remediarlo. Me gustaría saber qué problemas identificaron y resolvieron con "commit signing" .

Creo que lo que sucedió es que las personas confunden / confunden Autenticación con Autorización o tal vez Integridad de Código. Desafortunadamente, la Autenticación no es una Autorización o Integridad del Código a pesar de la voluntad de hacerlo.

¿Qué problema resuelve Git commit signing?


Me acerqué a alguien que se especializa en security, layout de experiencia de usuario y psicología de usuario. Él casi llegó a la misma conclusión. El layout y la psicología de UX son importantes porque es allí donde la goma se encuentra con la carretera y surgen problemas prácticos. Aquí estaba su respuesta:

El Jue, 22 de septiembre de 2016 a las 1:17 a.m., <networkingcated> escribió:

El proyecto Crypto ++ recogió una request para firmar Git commits, merges y / o pull requests. Cf., http://github.com/weidai11/cryptopp/issues/290 .

que piensas de eso? ¿Hay un beneficio abrumador para hacerlo? ¿Hay alguna diferencia entre decir "Lo rompí" y "Lo rompí <signed>"?

No puedo ver ningún beneficio para eso. Tenga en count que los comentarios son "deberíamos haber confirmado la firma", no "tenemos este problema, lo que confirmará que la firma corregirá". El problema es quién tiene acceso, no si está firmado o no. Si quiero subvertir el process, obtendré acceso de confirmación y enviaré mi puerta trasera en forma firmada. La protección es que alguien debe investigar el código enviado, no si está firmado o no.


Aquí hay una analogía del mundo real que puede ayudar a entender lo que estoy preguntando. Estoy haciendo esto porque algunas personas afirman que la pregunta es demasiado amplia o poco clara.

"Enviar posts de text y conducir" y "marcar y conducir" es un problema porque se traduce en una conducción distraída. La conducción distraída resulta en daños a la propiedad y lesiones humanas. Algunas legislaturas aprobaron leyes para hacer que el flujo de trabajo fuera ilegal, y los OEM del teléfono proporcionaron commands de voz, como Siri y Google Vocie, para facilitar flujos de trabajo less molestos.

En este caso, el problema es conducir distraído, y las soluciones fueron (1) política (hacerlo ilegal) y (2) procedimiento (proporcionar un flujo de trabajo alternativo).

Me interesa lo mismo cuando "confirmaciones firmadas son la solución" . Ellos son la solución a qué problema ?


Y aquí hay un ejemplo aún mejor en el context de Git. Traté de firmar una confirmación usando mis llaves GPG (tendré que verificar si están en el file con GitHub, o si solo mis keys SSH están en el file):

The Unverified es un problema que debe corregirse. Va a causar confusión a los usuarios y provocará un flujo interminable de preguntas. Más problemático es que seguí las instrucciones de GitHub en Signing commits usando GPG , y aún se muestra Sin verificar . La siguiente acción que tomaré solucionará un problema real .

enter image description here

El problema que confirma la firma de firmas es el mismo problema que resuelve la firma digital de un documento: el problema de verificar su autor.

Como solo el autor tiene su key privada, solo ellos pueden firmar el compromiso como ellos mismos.

Si confío en un comentarista en particular y ellos han firmado su compromiso, puedo confiar en su código sin necesariamente verificar manualmente cada línea.


Considere el caso en el que alguien bifurcó su repository en github y luego agregó un montón de confirmaciones que introdujeron vulnerabilidades de security en su código. Hicieron estos commits con el author name, author email, commit name, commit email la tupla author name, author email, commit name, commit email a uno de los autores originales.

Sin compromiso de firma, no hay forma de verificar que no son el autor original.

Con la firma de confirmación, estas confirmaciones falsificadas no se pueden firmar porque el falsificador no tiene la key privada del autor.