Cómo sellar en el tiempo un lanzamiento de software

El control de versiones te ofrece un historial excelente pero una fecha débil. Ancorar un lanzamiento soluciona el segundo problema en unos minutos por versión.

Por qué las fechas de git no bastan

Los sellos de tiempo de los commits los escribe la máquina que realiza el commit. Un rebase interactivo, un cambio en la hora del sistema o la bandera --date estándar pueden producir cualquier historial que desees, y el resultado parece completamente normal.

Esto está bien internamente. Como prueba es insuficiente, y la debilidad funciona en ambos sentidos: es igual de inútil cuando te defiendes de una reclamación que cuando la presentas tú.

Los propios sellos de tiempo de una plataforma alojada son mejores, pero pertenecen a la plataforma, desaparecen con la cuenta y un tercero no puede verificarlos de forma independiente.

Qué anclar

No el árbol de trabajo. Un artefacto determinista cuyos bytes puedas reproducir más tarde:

git archive --format=tar.gz -o release-v1.4.0.tar.gz v1.4.0

o un bundle, que captura tanto el historial como el contenido:

git bundle create release-v1.4.0.bundle v1.4.0

o la propia salida de compilación, si tu build es reproducible.

Luego haz hash de ese archivo y sella el hash en el tiempo.

Los pasos

1. Crea el artefacto a partir de la etiqueta (tag), no desde tu directorio de trabajo.
2. Haz hash — shasum -a 256, o la herramienta en el navegador, que produce una salida idéntica.
3. Sella el hash. El archivo se procesa con hash en tu navegador y solo se transmite el hash, lo cual es crucial cuando el código es propietario.
4. Guarda el certificado junto al lanzamiento, y registra a qué etiqueta corresponde.
5. Conserva el artefacto, byte a byte. Regenerarlo más tarde podría no producir los mismos bytes, ya que los formatos de archivo almacenan sellos de tiempo y orden.

Este último punto suele despistar a la gente. Un tar.gz reconstruido desde la misma etiqueta en otra máquina es frecuentemente un archivo diferente. Conserva el que has procesado con hash.

Hacerlo reproducible, si quieres saltarte el paso 5

Los archivos deterministas son alcanzables con esfuerzo: tiempos de modificación fijos, entradas ordenadas y nivel de compresión fijado. Si tu build ya es reproducible, hacer hash de la salida significa que cualquiera puede regenerarla y comprobarla de forma independiente, lo cual es más sólido que pedirles que confíen en tu copia almacenada.

Si no lo es, conservar el artefacto es totalmente razonable y mucho más barato que hacer que el build sea determinista solo para este propósito.

Qué te aporta esto

Firmar y sellar en el tiempo funcionan bien juntos y responden a preguntas distintas. Una etiqueta firmada demuestra quién la creó y que el contenido no ha sido modificado; la fecha de la firma sigue siendo la que la máquina del firmante afirmaba tener. Sellar en el tiempo fija el tiempo de forma independiente. Haz ambas cosas en los lanzamientos importantes.

Cuándo merece la pena hacerlo

Lanzamientos públicos donde la fecha pueda ser relevante en una cuestión de licencias o infracción.

Antes de una auditoría, depósito en custodia o adquisición: un registro fechado de exactamente qué se entregó.

Antes de revelar código a un cliente o socio, que es también el momento en que el código está más expuesto como secreto comercial. Consulta marca vs derechos de autor para código fuente.

Cuando usas una licencia permisiva y deseas constancia de que tu versión es anterior a las reclamaciones de un fork.

No merece la pena para cada commit. La idea es tener un pequeño número de anclas fechadas alrededor de estados que puedan necesitar defensa, no ceremonia en el trabajo ordinario.

Para la versión más amplia de este argumento, consulta timestamping blockchain para equipos de software.