Timestamp GIT Secure your prior art without exposing code

← Todos los artículos

2026-09-14

Instala una GitHub App para marcar la hora de tus commits automáticamente

Instala una GitHub App para marcar la hora de tus commits automáticamente
timestamp git blockchain proof

Instala una GitHub App para Sellar Temporalmente tus Commits de Forma Automática

Ya automatizas compilaciones, pruebas, linting y despliegues. Entonces, ¿por qué seguirías sellando temporalmente commits manualmente cuando necesitas demostrar autoría previa? La forma difícil es ejecutar herramientas de protocolo commit por commit y gestionar tú mismo los archivos de prueba. Timestamp GIT reemplaza eso con una GitHub App gestionada que sella temporalmente cada commit automáticamente y lo ancla a la blockchain de Bitcoin.

El flujo de trabajo es deliberadamente aburrido después de la configuración: instala la GitHub App una vez, selecciona los repositorios que deseas monitorear y deja que el pipeline nocturno cree recibos de prueba .ots. No hay CLI que instalar en las máquinas de los desarrolladores, no hay comandos manuales que recordar antes de un lanzamiento y no hay un archivo local frágil de sellos temporales.

Este artículo cubre la configuración inicial, qué ocurre entre el commit y el anclaje a Bitcoin, cómo monitorear las pruebas y las prácticas que mantienen tu evidencia segura ante un tribunal.

Configuración Inicial: Conecta la GitHub App

La automatización comienza con una sola instalación. Después de eso, la GitHub App para sellar temporalmente commits hace el trabajo repetitivo por ti.

1. Instala la GitHub App de Timestamp GIT

Instala la app en tu cuenta personal u organización desde el panel de Timestamp GIT. Durante la instalación, otorgas acceso al repositorio como con cualquier otra GitHub App.

En modo estándar, la app requiere:

  • Acceso de lectura al repositorio de origen. GitHub no ofrece un permiso solo de hash de commit, por lo que la app necesita al menos acceso de solo lectura para detectar los hashes de los commits.
  • Acceso de escritura al repositorio o rama de destino. Los archivos de prueba necesitan un lugar donde residir. Puede ser una rama dedicada timestamps en el repositorio de origen o un repositorio espejo separado.

Incluso con acceso de lectura, la app lee solo el hash del commit HEAD de los repositorios monitoreados. No lee archivos fuente, diffs, issues ni contenido de pull requests.

2. Selecciona los repositorios a monitorear

Después de la instalación, elige los repositorios que deben recibir sellado temporal automático. Los repositorios públicos están disponibles en el plan gratuito. Los repositorios privados requieren un plan Pro o Enterprise de pago, según tus necesidades de seguridad y cumplimiento.

No hay cambios en el código de la aplicación. No instalas nada en las máquinas de los desarrolladores y tu equipo no necesita cambiar su flujo de trabajo de commits.

3. Elige la entrega de pruebas

Por defecto, la app crea una rama Git dedicada o un repositorio espejo para los artefactos de prueba. Eso mantiene la evidencia separada de tu historial principal de código fuente y evita contaminar los pull requests con archivos .ots.

Modo Enterprise ZK: cero acceso al código

Si tu código es propietario, regulado o está en un entorno aislado, el modo Enterprise ZK es la opción más estricta. Una GitHub Action de 12 líneas se ejecuta en tu infraestructura y envía solo el hash del commit a la API de Timestamp GIT.

En este modo, la app de Timestamp GIT no necesita acceso de lectura a tu repositorio de origen en absoluto. Instalas la GitHub Action y solo los hashes de commit salen de tu entorno. Tu código fuente nunca lo hace.

Opcional: modo self-hosted con Docker

Para un control máximo, Timestamp GIT también está disponible como imagen Docker. Esto es útil para entornos aislados u organizaciones que deben mantener toda la infraestructura en sus instalaciones.

Una configuración mínima de 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

Levántalo con:

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

La aplicación está disponible en http://localhost:8080. En el primer arranque, un asistente de configuración te guía para conectar tu GitHub App y configurar la instancia.

El Pipeline Automatizado: Del Commit al Anclaje en Bitcoin

Una vez que la GitHub App está instalada, el proceso de sellado temporal se ejecuta por sí solo.

Paso 1: Detección de commits

En modo estándar, la GitHub App detecta nuevos commits a través de webhooks. En modo Enterprise ZK, tu GitHub Action envía los hashes de commit a la API como parte del CI/CD.

En cualquier caso, el único dato que entra en el pipeline de Timestamp GIT es el hash del commit.

Paso 2: Agrupación nocturna y anclaje a Bitcoin

Los hashes de commit se almacenan en un almacén clave-valor en memoria para su agrupación. Cada noche, un trabajador cron:

  1. Agrupa todos los hashes de commit pendientes.
  2. Crea un archivo de manifiesto para cada repositorio.
  3. Construye un árbol de Merkle a partir del lote diario.
  4. Crea pruebas OpenTimestamps usando calendarios OTS públicos.
  5. Ancla la raíz de Merkle en la blockchain de Bitcoin.

La raíz de Merkle diaria es lo que se incrusta en Bitcoin. Una vez que esa transacción se confirma, el hash queda permanentemente congelado en un bloque específico de Bitcoin.

Paso 3: Entrega de pruebas

Después de que la transacción de Bitcoin se confirma, Timestamp GIT envía el manifiesto y los archivos de recibo .ots de vuelta a la rama de timestamps dedicada o al repositorio espejo.

La confirmación de Bitcoin normalmente tarda alrededor de tres horas después de que se envía el lote nocturno. Eso significa que un commit realizado durante el día normalmente tendrá un archivo de prueba disponible al día siguiente.

Paso 4: Estado y verificación

Puedes ver el historial de anclajes desde el panel de estado del repositorio. El panel público muestra:

  • Longevidad de la prueba
  • Fecha de anclaje más temprana
  • Regularidad del anclaje diario
  • Datos de bloque y transacción de Bitcoin
  • Un mapa de calor de calendario
  • CSV de auditoría descargable y certificado PDF

Para acceso programático, hay endpoints de estado públicos disponibles:

# Información del último bloque de Bitcoin anclado
curl -s https://timestampgit.dev/api/statusLast/acme/payments-api

# Recuento total de commits confirmados y sellados
curl -s https://timestampgit.dev/api/statusCount/acme/payments-api

# Resumen combinado para insignias de Shields.io
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-api

El producto también proporciona un endpoint de insignias autenticado para que puedas generar insignias de README con una sola solicitud. Para repositorios privados, las URL de insignias incluyen un HMAC cifrado para que solo los usuarios autorizados puedan ver el estado.

Monitoreo y Manejo de Fallos

La automatización no significa ignorar el sistema. Debes monitorear la regularidad de los anclajes de la misma manera que monitoreas la salud del CI.

El panel de estado es el lugar más rápido para detectar un día faltante. Si un lote nocturno no produce una prueba, la fecha faltante será visible como un hueco en el mapa de calor del calendario y en la vista de regularidad diaria.

Para verificaciones programáticas, los mismos endpoints anteriores pueden alimentar tu monitoreo interno:

  • Usa /api/statusLast/{user}/{repo} para confirmar el anclaje de Bitcoin más reciente.
  • Usa /api/statusCount/{user}/{repo} para comparar los commits sellados con el recuento de commits esperado.
  • Usa /api/audit/{user}/{repo} para descargar el libro de auditoría completo como CSV.

Ejemplo:

# Descargar el libro de auditoría completo
curl -OJ https://timestampgit.dev/api/audit/acme/payments-api

# Descargar un certificado PDF para una fecha específica
curl -OJ https://timestampgit.dev/api/report/acme/payments-api/2026-09-13

Debido a que el sistema agrupa hashes a medianoche y la confirmación de Bitcoin tarda alrededor de tres horas, no trates un commit recién enviado como completamente sellado hasta que el archivo de prueba aparezca en la rama de timestamps.

Finalmente, cualquiera puede verificar de forma independiente un archivo .ots contra la blockchain de Bitcoin. La prueba se basa en recibos OpenTimestamps estándar y datos de bloques de Bitcoin, por lo que la verificación no depende de que Timestamp GIT siga disponible.

Mejores Prácticas para el Sellado Temporal Automatizado

1. Actívalo en todos los repositorios críticos

Sellar temporalmente solo repositorios públicos deja el trabajo interno privado desprotegido. Los trolls de patentes y las disputas laborales a menudo involucran sistemas propietarios que nunca salen de tu infraestructura. Usa los planes de repositorios privados o el modo Enterprise ZK para esos casos.

2. Usa el modo Enterprise ZK para secretos comerciales

Si un repositorio contiene secretos comerciales o código regulado, no otorgues acceso de lectura a ninguna app de terceros. Usa la GitHub Action para que solo los hashes de commit salgan de tu entorno.

3. Protege la rama de timestamps

Los recibos .ots y los archivos de manifiesto son tu evidencia. Trata la rama de timestamps dedicada o el repositorio espejo como almacenamiento de evidencia inmutable. Restringe el acceso de escritura a la app y a los administradores requeridos.

4. Archiva los registros de auditoría regularmente

Descarga los CSV de auditoría y los certificados PDF según un calendario, como trimestralmente o antes de lanzamientos importantes. Guarda copias en tu archivo de cumplimiento o legal. La prueba de blockchain existe de forma independiente, pero tener el rastro de auditoría organizado facilita mucho la revisión legal.

5. Añade una insignia de verificación a tu README

Las insignias de verificación públicas son una forma sencilla de indicar que un repositorio tiene sellado temporal automático habilitado. Usa el enlace de insignia del panel o de la API autenticada para incrustar una insignia de Shields.io en tu README.

Preguntas Frecuentes

¿La GitHub App lee mi código fuente?

No. En modo estándar, la app lee solo el hash del commit HEAD. En modo Enterprise ZK, una GitHub Action de tu lado envía solo el hash del commit a la API, por lo que la app nunca tiene acceso a tu repositorio.

¿Cuánto tarda en sellarse temporalmente un commit?

Los commits se recopilan durante todo el día y se anclan a Bitcoin en un lote nocturno. Después de enviar el lote, la confirmación de Bitcoin normalmente tarda unas 3 horas. Recibes el archivo de prueba .ots una vez confirmado.

¿Puedo verificar el sello temporal sin usar Timestamp GIT?

Sí. Las pruebas son archivos OpenTimestamps .ots estándar. Cualquiera puede descargar el archivo y verificarlo localmente contra la blockchain de Bitcoin usando herramientas de código abierto. Timestamp GIT también proporciona un verificador basado en web y certificados PDF.

¿Está disponible el self-hosting?

Sí. Timestamp GIT ofrece una imagen Docker para self-hosting, adecuada para entornos aislados o altamente regulados. Una licencia demo con límite de tiempo está disponible bajo solicitud.

Conclusión: Configúralo y Olvídate

El sellado temporal manual es frágil porque depende de que alguien recuerde hacerlo. Un pipeline basado en GitHub App elimina ese modo de fallo.

Con Timestamp GIT, instalas una vez, seleccionas repositorios y dejas que el trabajador nocturno ancle los hashes de commit a Bitcoin. Tu equipo sigue escribiendo código con normalidad. La evidencia se acumula automáticamente como archivos .ots, informes de auditoría e insignias de estado.

Instala la Timestamp GIT GitHub App hoy, o comienza con el plan gratuito para repositorios públicos. Los planes Pro y Enterprise están disponibles para repositorios privados y despliegues de conocimiento cero más estrictos.

Publicaciones relacionadas

EU label: AI-generated content