Horodatage Git auto-hébergé avec Docker : un guide

La tâche manuelle répétitive que vous éliminez est la suivante : chaque fois que vous voulez une preuve cryptographiquement défendable qu’un commit Git a existé à une certaine date, soit vous exécutez des commandes d’horodatage à la main, soit vous poussez des métadonnées vers un service que vous ne contrôlez pas entièrement. Pour les startups, les ateliers de développement et les équipes soucieuses de conformité, cela crée une faille. Les étapes manuelles sont sautées. Les dépendances externes soulèvent des questions de souveraineté des données. Les environnements réglementés ou isolés du réseau ne peuvent souvent pas du tout utiliser un SaaS géré.

La méthode difficile consiste à exécuter OpenTimestamps vous-même et à surveiller chaque reçu. La méthode pratique consiste à déployer Timestamp GIT comme application Docker auto-hébergée : la même automatisation basée sur une GitHub App, l’ancrage nocturne dans Bitcoin et les badges de vérification fonctionnent sur une infrastructure que vous possédez.

Si vous avez besoin d’un rappel sur l’importance de la preuve d’existence dans les logiciels avant de continuer, consultez Preuve d’existence dans les logiciels : guide du débutant.

Pourquoi auto-héberger l’horodatage Git ?

Auto-héberger Timestamp GIT ne consiste pas à éviter le service géré. Il s’agit d’exécuter exactement la même automatisation derrière votre propre pare-feu, avec votre propre volume de données, votre propre licence et vos propres règles réseau. Cela compte lorsque :

• Vous avez besoin de souveraineté des données et ne voulez pas que les métadonnées de commit quittent votre environnement au-delà de l’étape d’ancrage Bitcoin.
• Vous opérez dans un environnement réglementé ou isolé du réseau où les connexions SaaS tierces sont restreintes.
• Vous voulez un contrôle total sur les identifiants de la GitHub App, l’emplacement de stockage et l’accès aux journaux.
• Vous avez besoin d’un déploiement adapté à l’audit qui reste sous le contrôle opérationnel de votre équipe.

L’option Docker auto-hébergée vous offre le même pipeline automatisé : installez la GitHub App une fois, connectez les dépôts et laissez l’instance regrouper les hachages de commit chaque nuit, construire des preuves de Merkle et les ancrer dans Bitcoin. Après la configuration unique, il n’y a aucune étape d’horodatage manuelle.

Configuration unique : déployer Timestamp GIT avec Docker

Le déploiement est une seule pile Docker Compose avec deux services : l’application Timestamp GIT et une instance Valkey utilisée comme file d’attente de hachages.

Créez un fichier docker-compose.yml avec la configuration exacte de la documentation produit :

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

Puis exécutez :

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

L’application devient disponible à l’adresse http://localhost:8080 après le démarrage. Au premier lancement, un assistant de configuration vous guide pour connecter votre GitHub App et configurer votre instance. C’est là que vous effectuez l’intégration unique. Vous n’installez rien sur les machines des développeurs et vous ne répétez pas d’étapes d’horodatage manuelles par la suite.

Vous avez besoin d’un fichier de licence monté à ./license.lic. Une licence de démonstration à durée limitée est disponible en remplissant le formulaire de demande sur la page de licence Docker avec votre nom, votre entreprise, votre e-mail et éventuellement votre numéro de téléphone. Pour une utilisation en production, utilisez une licence commerciale.

Une fois l’assistant terminé, le processus d’horodatage continu est entièrement automatisé.

Le pipeline automatisé : du commit à l’ancrage Bitcoin

Une fois déployée, l’instance auto-hébergée exécute le même flux de travail sans configuration que le service géré Timestamp GIT.

Détection des commits

Il existe deux modes de détection :

• Mode standard (GitHub App) : la GitHub App détecte les nouveaux commits via des webhooks. Elle lit uniquement le hachage du commit HEAD de chaque dépôt surveillé et envoie ce hachage à votre instance auto-hébergée.
• Mode Enterprise ZK : une GitHub Action de 12 lignes s’exécute sur votre infrastructure et pousse uniquement le hachage du commit vers l’API Timestamp GIT. Dans ce mode, le code source ne quitte jamais votre environnement et l’instance Timestamp GIT n’a besoin d’aucun accès en lecture au dépôt source.

File d’attente de hachages et traitement par lots nocturne

Les hachages de commit entrants sont stockés dans la file d’attente adossée à Valkey. Chaque nuit, un worker cron à l’intérieur du conteneur Timestamp GIT :

1. Regroupe tous les hachages en attente pour chaque dépôt.
2. Crée un fichier manifeste quotidien (.txt) pour chaque dépôt.
3. Construit un arbre de Merkle nativement.
4. Crée des preuves OpenTimestamps en utilisant des calendriers OTS publics.
5. Ancre la racine de Merkle dans la blockchain Bitcoin.

Livraison des preuves

Le manifeste et les fichiers de reçus .ots sont renvoyés vers une branche d’horodatage dédiée ou un dépôt fantôme, selon la façon dont vous avez configuré la GitHub App. Cela se produit automatiquement après la confirmation de l’ancrage Bitcoin.

La confirmation Bitcoin prend normalement quelques heures, donc les preuves n’apparaissent pas instantanément après minuit. Si vous committez à 15h00, ce hachage est pris en compte lors de la prochaine exécution nocturne et est généralement ancré et livré quelques heures plus tard.

Surveillance et gestion des échecs

Vous pouvez surveiller l’état d’ancrage directement via les points de terminaison API exposés par votre instance auto-hébergée.

Points de terminaison d’état

Pour tout dépôt public, vous pouvez interroger :

curl https://timestampgit.example.com/api/statusLast/acme/checkout-service

Cela renvoie du JSON avec les informations du dernier bloc Bitcoin ancré.

curl https://timestampgit.example.com/api/statusCount/acme/checkout-service

Cela renvoie le nombre total de commits effectués et horodatés.

curl https://timestampgit.example.com/api/statusSummary/acme/checkout-service

Cela renvoie un résumé combiné adapté aux badges Shields.io.

Les dépôts privés ajoutent un HMAC chiffré à l’URL, de sorte que seuls les utilisateurs autorisés peuvent consulter leur état. Le HMAC est spécifique à votre instance de serveur auto-hébergée.

Tableau de bord public

Chaque dépôt dispose également d’un tableau de bord d’état public à l’adresse :

https://timestampgit.example.com/status/{user}/{repo}

Cette page affiche la longévité des preuves, la date d’ancrage la plus ancienne, la régularité quotidienne, les données de bloc et de transaction Bitcoin, une carte de chaleur calendaire, un CSV d’audit téléchargeable et un certificat PDF.

Scénarios d’échec

• Si le worker cron échoue, consultez les journaux du conteneur :

docker compose logs -f timestampgit

• Si le réseau Bitcoin retarde la confirmation, les points de terminaison d’état n’afficheront pas encore de nouvel ancrage. C’est généralement temporaire.
• L’instance auto-hébergée stocke ses données dans le volume ./data. Redémarrer ou recréer les conteneurs ne fait pas perdre les hachages en file d’attente ni la configuration.
• Configurez des alertes basées sur l’API d’état ou la sortie des journaux. Une vérification quotidienne de /api/statusLast suffit pour la plupart des équipes. Si la date du dernier ancrage cesse d’avancer, examinez le conteneur et l’accès réseau sortant.

Bonnes pratiques pour l’horodatage Git auto-hébergé

• Restreignez l’accès réseau à l’hôte Docker. Utilisez des règles de pare-feu et des proxys inverses. N’exposez que les ports qui doivent être joignables par les webhooks GitHub ou votre réseau interne.
• Sauvegardez le volume ./data et le fichier license.lic. Le volume contient les hachages en file d’attente et la configuration de l’instance. Le fichier de licence doit rester lisible par le conteneur.
• Utilisez une GitHub App dédiée avec des permissions minimales. En mode standard, l’application a besoin d’un accès en lecture seule aux dépôts sources et d’un accès en lecture-écriture au dépôt cible où les preuves sont stockées. Le mode Enterprise ZK nécessite uniquement un accès en lecture-écriture au dépôt cible.
• Privilégiez un dépôt fantôme pour les preuves. Cela garde votre dépôt principal propre et sépare l’historique source des reçus d’horodatage.
• Vérifiez régulièrement les horodatages. Utilisez la page de vérification publique ou l’API pour confirmer que les reçus .ots se vérifient toujours par rapport aux données de bloc Bitcoin. C’est particulièrement important avant un événement juridique ou de conformité.
• Mettez à jour les images de conteneur délibérément. Utilisez docker compose pull pendant une fenêtre de maintenance et vérifiez la nouvelle version sur une instance de préproduction avant de passer en production.

FAQ

Q : Puis-je exécuter Timestamp GIT dans un environnement totalement isolé du réseau ?

R : Oui, la version Docker auto-hébergée est conçue pour une sécurité maximale et peut fonctionner dans des environnements isolés du réseau. Cependant, elle doit toujours s’ancrer à la blockchain Bitcoin, donc l’instance doit avoir un accès Internet sortant pour atteindre les nœuds Bitcoin ou les calendriers OpenTimestamps. Si un isolement total est requis, vous aurez peut-être besoin d’un proxy ou d’un relais pour l’étape d’ancrage.

Q : Comment obtenir une licence pour la version Docker auto-hébergée ?

R : Vous pouvez demander une licence de démonstration à durée limitée en remplissant le formulaire sur la page de licence Docker avec votre nom, votre entreprise, votre e-mail et éventuellement votre numéro de téléphone. Un fichier de licence vous sera fourni pour évaluation. Pour une utilisation en production, contactez le fournisseur pour une licence commerciale.

Q : La version auto-hébergée nécessite-t-elle une GitHub App ?

R : Oui, l’instance Timestamp GIT auto-hébergée utilise toujours une GitHub App pour détecter les commits et renvoyer les preuves vers vos dépôts. Pendant l’assistant de configuration, vous connecterez les identifiants de votre GitHub App. L’application nécessite un accès en lecture seule aux dépôts sources et un accès en lecture-écriture au dépôt cible où les preuves sont stockées.

Q : Quelles sont les exigences en ressources pour exécuter Timestamp GIT avec Docker ?

R : Les informations produit ne précisent pas d’exigences exactes en ressources, mais le Docker Compose comprend deux services : l’application Timestamp GIT et une instance Valkey (compatible Redis) pour la file d’attente de hachages. Pour les équipes de petite et moyenne taille, un VPS modeste avec 1 à 2 Go de RAM devrait suffire. Surveillez l’utilisation des ressources et faites évoluer selon les besoins.

Conclusion

L’horodatage Git auto-hébergé avec Docker élimine le travail manuel fastidieux de la protection d’antériorité. Vous déployez la pile une fois, connectez la GitHub App, et chaque commit vers un dépôt surveillé passe par un pipeline automatisé : détection des hachages, traitement par lots nocturne, création de preuves de Merkle, ancrage Bitcoin et livraison des preuves vers votre dépôt.

C’est la différence entre une protection juridique que vous utilisez réellement et une qui devient une corvée. Si vous êtes prêt à déployer, commencez par la pile Docker Compose ci-dessus et demandez une licence de démonstration sur la page de licence Docker. Pour les équipes qui préfèrent ne pas exploiter leur propre instance, le service géré Timestamp GIT offre la même automatisation sans auto-hébergement.

Articles connexes

• Comment horodater cryptographiquement des commits Git (sans outils CLI)
• Tarification de Timestamp GIT : des plans pour chaque développeur
• Preuve d’existence dans les logiciels : guide du débutant