Firmar imágenes y binarios

Una firma de imagen se asocia al digest, el resumen del contenido exacto. Si se firma una etiqueta, lo que realmente se firma es el digest al que la etiqueta apuntaba en ese momento, pero el comando se escribió con un nombre movible: quien lo lea después no sabe qué contenido se firmó, y la etiqueta puede moverse a otra imagen sin firma.

Por eso el flujo correcto sube la imagen, recoge el digest que el registro devuelve y firma nombre@digest. Lo que se firma y lo que se despliega es lo mismo.

Abre los tres flujos y mira el último paso de cada uno. Dos firman un nombre con digest o un archivo concreto; uno firma una referencia que se puede mover. Ese flujo, además, se dispara a mano y fuera de la cadena normal, que es justo la situación en la que más cuesta saber qué se firmó.

Un binario o cualquier archivo no vive en un registro de imágenes, así que no hay dónde colgarle la firma. Para eso existe la firma de archivos (sign-blob): firma el archivo y deja la firma y el certificado en un archivo aparte, un «bundle», que se publica junto al binario. Quien descarga necesita los dos archivos para verificar.

Abre el flujo de la herramienta de línea de órdenes y localiza el archivo que se adjunta con la firma.

Para que el flujo obtenga un token de identidad necesita un permiso explícito, en GitHub Actions el permiso id-token: write. Si se concede a todo el flujo, cada tarea del flujo puede pedir una identidad firmable. Concederlo solo a la tarea que firma limita qué pasos pueden convertirse en esa identidad, y es la misma idea de mínimo privilegio que se aplica al token de acceso al repositorio.

Los tres flujos usan firma sin clave: ninguno guarda una clave privada. Pero el tercero firma algo cuyo contenido nadie puede reconstruir mirando el comando, y se puede lanzar a mano. La firma sin clave elimina un riesgo, el robo de la clave, y deja intactos los demás: qué entra en el flujo, quién puede lanzarlo y desde qué rama.