Sellado de tiempo automatizado de Git: cómo una GitHub App ancla cada commit

2026-10-05 timestamp git blockchain proof

Sellado de tiempo automático en Git: cómo una GitHub App ancla cada commit

Haces push de un commit que importa — el núcleo de una funcionalidad de la que tendrás que demostrar que construiste primero. Con el enfoque manual, ese es el momento en que tu flujo se rompe. Te detienes, cambias de contexto y comienzas un pequeño ritual de herramientas locales y gestión de pruebas para fijar el commit a un punto en el tiempo. Luego lo haces de nuevo en el siguiente commit, y en el siguiente, hasta el día en que lo olvidas.

Esa es la trampa del sellado de tiempo manual. Los registros de prior art son tan sólidos como su densidad y su regularidad, y los registros basados en procesos humanos no son ni lo uno ni lo otro. Los desarrolladores se saltan el paso durante un apuro, lo configuran mal en una máquina nueva o nunca lo configuran en el repositorio que resulta ser el importante. Las lagunas en la cadena son exactamente lo que busca un abogado de la parte contraria o un auditor.

Este artículo trata de eliminar por completo al humano de ese bucle con el sellado de tiempo automático en Git mediante una GitHub App. Una instalación, y cada commit a un repositorio monitorizado queda huellado y anclado en Bitcoin cada noche — por una máquina, según un calendario, sin que nadie escriba un comando.

Esto es un recorrido de automatización, no una inmersión profunda en criptografía. Para el porqué, consulta Proteger la propiedad intelectual: una guía para desarrolladores de software y Protección de prior art para startups de software: una guía. Para la mecánica de verificar una prueba más adelante, consulta Verificar sellos de tiempo de código sin compartir tu código fuente.

(Para contexto: el enfoque crudo consiste en ejecutar las herramientas de OpenTimestamps a mano, por commit, y gestionar tus propios envíos a los calendarios. Es la forma difícil. Todo lo que sigue es la vía automatizada.)

Configuración única: instala la GitHub App y olvídate

Timestamp GIT es un SaaS gestionado construido en torno a una GitHub App. La instalas una vez contra un repositorio o una organización entera, y la automatización toma el control.

Hay dos modos de despliegue, y eliges según cuánto acceso estés dispuesto a conceder:

Modo estándar (GitHub App). La GitHub App lee únicamente el hash del commit HEAD de tu repositorio monitorizado — automáticamente, en cada push. Las pruebas se escriben en una rama dedicada del mismo repositorio o en un repositorio sombra separado. Como el modelo de permisos de GitHub no ofrece un alcance de “solo hash de commit”, este modo requiere acceso de solo lectura al repositorio de origen y acceso de lectura-escritura al repositorio de destino donde aterrizan las pruebas.

Modo Enterprise ZK (GitHub Action). El paso de recolección se traslada a tu propio CI. Una GitHub Action de 12 líneas se ejecuta en tus runners, extrae el hash HEAD y envía solo ese hash a la API de Timestamp GIT. El compromiso es explícito: tú te quedas con el acceso de lectura, y Timestamp GIT necesita acceso de lectura-escritura solo al repositorio de destino. Ni el código fuente ni el acceso de lectura al repositorio cruzan nunca la frontera.

Dos cosas que vale la pena señalar sobre la configuración:

No se instala nada en las máquinas de los desarrolladores. Ni CLI, ni daemon local, ni deriva de configuración por portátil. La app se ejecuta en la infraestructura de GitHub y en nuestro backend; la Action se ejecuta en runners alojados por GitHub o autoalojados.
No hay configuración continua. Tras la instalación, la app detecta nuevos commits mediante webhooks. Nadie tiene que recordar nada.

Puedes revisar y gestionar qué repositorios están monitorizados desde tu página de repositorios después de la instalación.

El pipeline automatizado: del commit al anclaje en Bitcoin

Una vez instalada la app, esto es lo que ocurre realmente entre git push y la aparición de un archivo de prueba inmutable en tu repositorio.

1. Detección de commits y agrupación en lotes

Un webhook se dispara con los nuevos commits. La app — o tu Action, en el Modo Enterprise ZK — extrae el hash del commit y lo introduce en un almacén clave-valor en memoria. Ese almacén es una cola, no un libro mayor; existe puramente para acumular hashes hasta que se ejecute el lote nocturno.

Solo se mueve el hash. Nunca el diff, nunca el contenido de los archivos, nunca el historial de ramas.

2. El worker cron de medianoche

Cada noche, un worker recoge cada hash pendiente y:

Los agrupa por repositorio y escribe un archivo manifiesto (.txt) por repositorio.
Construye un árbol de Merkle de forma nativa sobre el lote.
Crea pruebas de OpenTimestamps usando servidores de calendario públicos.
Ancla la raíz de Merkle en la blockchain de Bitcoin.

Ese último paso es el que hace inmutable el registro. Una vez que la raíz se confirma en un bloque de Bitcoin, ninguna entidad — incluida Timestamp GIT — puede alterarla o falsificarla a posteriori.

3. Entrega de pruebas

Tras el anclaje, el manifiesto y los archivos de recibo .ots correspondientes se envían de vuelta a tu repositorio, ya sea en una rama dedicada de sellos de tiempo o en un repositorio sombra.

Calcula unas cuantas horas para esto. La confirmación de Bitcoin suele tardar alrededor de 3 horas, así que las pruebas generalmente aterrizan unas horas después de la ejecución nocturna en lugar de inmediatamente.

Modo Enterprise ZK: el único modo con un archivo de workflow

Este es el único lugar en el que jamás mirarás YAML. El asistente de configuración genera el workflow con tu endpoint y tu secreto prerrellenados; se ve aproximadamente así:

name: Timestamp commit hash
on: [push]
jobs:
  anchor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - name: Send HEAD hash to Timestamp GIT
        env:
          TSG_ENDPOINT: ${{ secrets.TIMESTAMPGIT_ENDPOINT }}
        run: curl -fsS -X POST "$TSG_ENDPOINT" --data "$(git rev-parse HEAD)"

Esa es toda la integración. Hay un recorrido dedicado en GitHub Action para el sellado de tiempo de commits: guía de configuración si quieres profundizar en este modo.

Pipelines personalizados: la ZK Commit API

Si necesitas integrar el sellado de tiempo en algo distinto del flujo estándar, la ZK Commit API acepta hashes de commit directamente. Se autentica con HMAC — el valor del hash de la URL firmada debe acompañar a la petición — así que una URL filtrada por sí sola no basta para escribir en tu libro mayor.

Para automatización de solo lectura, los endpoints públicos de estado son más sencillos:

# Last anchored Bitcoin block for a repo
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo

# Total stamped commit count
curl -s https://timestampgit.dev/api/statusCount/your-org/your-repo

# Combined summary (what the Shields.io badge consumes)
curl -s https://timestampgit.dev/api/statusSummary/your-org/your-repo

Monitorización y gestión de fallos

Una automatización que no puedes auditar no es una automatización en la que puedas confiar en una disputa. Timestamp GIT expone el estado de tu cadena de pruebas en tres lugares.

El panel de estado público

/status/{user}/{repo} muestra la longevidad de las pruebas, la fecha de anclaje más temprana, la regularidad diaria y los datos del bloque y la transacción de Bitcoin detrás de cada anclaje. Hay un mapa de calor tipo calendario para que las lagunas sean visualmente obvias, además de exportaciones descargables de auditoría en CSV y certificados en PDF.

La regularidad es la métrica que hay que vigilar. Un mapa de calor con huecos es una historia de prior art más débil que uno sólido.

Insignias de verificación

Puedes incrustar insignias de Shields.io en tu README para mostrar públicamente el estado de verificación. El widget en /connected/{user}/{repo} te da una vista previa en vivo y el fragmento de markdown, y /api/badgeLink/{user}/{repo} devuelve las URLs de las insignias y el fragmento de forma programática.

Los repositorios privados añaden un HMAC cifrado a las URLs de la insignia y del estado, con alcance a la instancia del servidor. Eso significa que la insignia sigue renderizándose mientras solo los usuarios autorizados pueden resolver los datos de estado subyacentes.

Cuando falla una ejecución nocturna

El fallo más probable es que la congestión de la red de Bitcoin retrase la confirmación. El sistema reintenta en lugar de descartar el lote. Comprueba el estado mediante el panel, o mediante la API si vas a integrar esto en tu propio sistema de alertas:

# Confirm the latest anchored block; a stale value means the last run didn't land
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo | jq .

Si necesitas evidencia puntual para cumplimiento normativo, extrae los artefactos directamente:

# Full audit ledger as CSV
curl -sO https://timestampgit.dev/api/audit/your-org/your-repo

# PDF certificate for a specific date
curl -sO https://timestampgit.dev/api/report/your-org/your-repo/2026-10-04

Cualquiera puede también verificar de forma independiente el sello de tiempo de un solo día a través de /verification/{user}/{repo}/{date}, donde el cálculo completo de la cadena de Merkle ocurre localmente en el navegador. Nadie — incluida Timestamp GIT — ve lo que verificas.

Entornos aislados (air-gapped)

Si tu postura de seguridad no permite en absoluto un servicio gestionado, Timestamp GIT se distribuye como imagen de Docker. Una configuración rápida de Docker Compose se ve así:

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

La aplicación está disponible en http://localhost:8080 tras el arranque, y un asistente de configuración te guía para conectar tu GitHub App y configurar la instancia en el primer inicio. Hay disponible una licencia de demostración por tiempo limitado para evaluación a través de la página de licencia de Docker. Sellado de tiempo en blockchain autoalojado con Docker cubre esa vía en detalle.

Buenas prácticas para el sellado de tiempo automatizado

Haz commits con regularidad, en fragmentos de tamaño razonable. Cada commit añade una hoja al árbol de Merkle diario. Una cadena densa es un registro de prior art más sólido que cuatro commits gigantes por trimestre.
Escribe mensajes de commit significativos. Solo se sellan los hashes, pero durante una auditoría tendrás que correlacionar las pruebas con las funcionalidades. Unos buenos mensajes hacen que ese mapeo sea trivial.
Configura alertas ante anclajes obsoletos. Una insignia verde debería significar que una ejecución reciente tuvo éxito, no que hubo una ejecución una vez en marzo.
Deja el workflow en paz. El mayor riesgo del sellado de tiempo automatizado es que alguien “mejore” el pipeline. La configuración por defecto no tiene pasos manuales por una razón.
Recurre al Modo Enterprise ZK cuando tu código fuente no pueda leerse. Si el cumplimiento normativo prohíbe conceder acceso de lectura al repositorio a un tercero, ejecuta la Action en tus propios runners.
Dile a tu equipo que es automático. Los ingenieros que creen que el sellado de tiempo es una tarea manual acabarán intentando hacerlo a mano, y así es como aparecen entradas duplicadas o malformadas.

Puedes empezar desde timestampgit.dev — instala la app, conecta un repositorio y deja que se ejecute el primer lote nocturno.

FAQ

P: ¿Necesito cambiar mi flujo de trabajo de Git para usar el sellado de tiempo automatizado? R: No. Una vez que instalas la GitHub App de Timestamp GIT, detecta automáticamente los nuevos commits mediante webhooks y les pone sello de tiempo cada noche. Tú sigues haciendo commits como siempre — sin comandos ni pasos adicionales.

P: ¿Qué ocurre si uso múltiples ramas o repositorios? R: La GitHub App monitoriza todas las ramas de los repositorios a los que concedas acceso. También puedes configurar qué repositorios se monitorizan. Para varios repositorios, cada uno obtiene su propio manifiesto y sus propios archivos de prueba.

P: ¿Está mi código fuente expuesto alguna vez a Timestamp GIT? R: No. En el Modo estándar, la app lee únicamente el hash del commit HEAD — nunca tu código fuente. En el Modo Enterprise ZK, una GitHub Action en tu infraestructura envía solo el hash del commit a nuestra API, así que tu código nunca sale de tu entorno.

P: ¿Cuánto tarda un commit en recibir su sello de tiempo? R: Los hashes de commit se agrupan en lotes y se anclan en Bitcoin una vez por noche. Tras la ejecución nocturna, la transacción de Bitcoin suele tardar alrededor de 3 horas en confirmarse, tras lo cual los archivos de prueba .ots se envían de vuelta a tu repositorio.

Conclusión

El sellado de tiempo manual falla por la misma razón por la que falla todo el cumplimiento manual: depende de que un humano lo recuerde, siempre, para siempre. La GitHub App elimina esa dependencia. Instálala una vez, y cada commit en tus repositorios monitorizados queda huellado, agrupado en lotes, con raíz de Merkle y anclado en Bitcoin según un calendario nocturno — con insignias, un panel de estado público, un CSV de auditoría, certificados en PDF y verificación local en el navegador como respaldo.

Si estás evaluando esto para un equipo, empieza con un único repositorio privado y observa cómo se llena el mapa de calor de la primera semana. Luego decide hasta dónde desplegarlo.

Instala la GitHub App, conecta tu primer repositorio y deja que el worker de medianoche haga el resto.

Entradas relacionadas

Proteger la propiedad intelectual: una guía para desarrolladores de software
Protección de prior art para startups de software: una guía
GitHub Action para el sellado de tiempo de commits: guía de configuración

Sellado de tiempo automatizado de Git: cómo una GitHub App ancla cada commit