(Esto se basa en gran medida en Una historia de Git Horror: Integridad del repositorio con compromisos firmados : muy buena lectura, y más información de la que podría poner en una respuesta.)
Hay varias formas en que un repositorio de git puede verse comprometido (esto no es un defecto de seguridad, solo un hecho de la vida, no se debe evitar el uso de git debido a esto). Por ejemplo, alguien puede haber empujado a su repositorio diciendo ser usted. O, para el caso, alguien podría haber presionado al repositorio de else que dice ser usted (alguien podría presionar a su propio repositorio que dice ser usted también). Esto es solo parte de la vida en un DVCS.
Solo como ejemplo:
$ git config --global user.name 'Madara Uchiha'
$ git config --global user.email [email protected]
Allí, he cambiado mi configuración de git para fingir que soy tú. Y ahora puedo comprometerme y dejar que esos compromisos de alguna manera lleguen a la compilación de producción, y parece que lo has hecho.
Con la firma de las confirmaciones (y etiquetas), uno puede probar que ciertas confirmaciones y etiquetas fueron suyas (y las cosas que no están firmadas no deberían haber ingresado en la compilación de producción). Esa es realmente la clave de todo: al firmar los compromisos, ha dicho que es su trabajo.
El aspecto de "su trabajo" es particularmente importante en el kernel de Linux (y por lo tanto git) que ocasionalmente se ve afectado por demandas de derechos de autor. Al firmar confirmaciones, usted dice que tiene derecho al software: rastrea el origen. Es posible que no tenga acceso a la fuente que se reclama como copyright y que la reclamación no tenga fundamento. Es posible que la empresa haya olvidado que estaba trabajando para ellos hace unos años y bajo su dirección agregó material al núcleo, o lo que sea.
Hay cierto debate sobre si cada compromiso debe ser firmado. Desde ¿GPG está firmando para git commit? (de nuevo en '09 ), Linus escribió:
Firmar cada commit es totalmente estúpido. Solo significa que lo automatiza y hace que la firma valga menos. Tampoco agrega ningún valor real, ya que en la forma en que git DAG-chain de SHA1 funciona, solo necesita una firma para hacer que todas las confirmaciones a las que se pueda acceder estén cubiertas por esa. Así que al firmar cada confirmación simplemente falta el punto.
También se puede leer mucho más sobre los pensamientos sobre el inicio de sesión en git allí.
Dicho esto, se abrió camino en git de todos modos.
Parece que hay un consenso mayoritario de que firmar confirmaciones es innecesario, pero la firma de etiquetas es muy buena. Esa publicación de blog vinculada en la parte superior sugiere que uno debe firmar todo de todos modos. Como dije, hay un debate acerca de si cada compromiso es necesario o no.
La clave para el debate "firmar cada compromiso" probablemente tenga que ver con el flujo de trabajo que utiliza. La mayoría de las personas hacen un montón de confirmaciones en su repositorio local y luego presionan ese conjunto. Debería ser suficiente para etiquetar la colección final (suponiendo, es decir, asegurarse de que todos los cambios sean correctos). Si está trabajando en un entorno en el que se mueven muchas confirmaciones individuales, la distinción entre una etiqueta y una confirmación se vuelve menos ... distinta, y la firma de confirmaciones puede ser más útil.