Commits firmados y verificación de identidad

Git sabe firmar commits con claves GPG o SSH. Al revisar un historial, git log informa un estado de firma por commit: G es una firma buena, B una mala, U una buena con validez desconocida, X una buena caducada, Y una buena de una clave caducada, R una buena de una clave revocada, E que no se puede comprobar y N que no hay firma.

Una firma buena prueba que esa clave firmó ese contenido. No prueba que la clave pertenezca a quien figura como autor: eso depende del registro que la empresa lleva de quién es cada clave. Por eso se compara el titular de la clave con el autor, y se retiran las claves de quienes se van.

Cuando una persona deja la empresa, su clave se marca como revocada en el registro. Un commit firmado con esa clave después de la revocación merece una pregunta: ¿quién tenía la clave? Ojo: la fecha de un commit también la escribe quien commitea, así que el estado R es el motivo para investigar, no una conclusión.

Abre el informe de la rama principal y la leyenda de estados.

El informe trae una columna con el titular de la clave, sacada del registro de la empresa. En una rama donde la firma importa, la autoría de cada commit debería coincidir con el titular de la clave que lo firmó. Si no coincide, o alguien firmó con la clave de otra persona, o el registro está mal.

La política de firma de este repositorio está aprobada pero sin activar. Mientras no se active, la rama acepta commits sin firma y el historial lo muestra. Mide la distancia hasta poder exigirla.

Exigir commits firmados en la rama principal es una opción de protección que el servidor aplica. Pero con las claves sin titular claro, con una revocada aún en circulación y con commits suplantables por una clave ajena, activarla sin más produciría bloqueos y una falsa sensación de seguridad.