Vérifiez les horodatages de code sans partager votre code source

La vérification est le moment où une revendication cryptographique devient une preuve. Vous pouvez horodater chaque commit, mais si vous ne pouvez pas vérifier cet horodatage plus tard sans remettre votre source, le système échoue précisément au moment où vous en avez le plus besoin. Timestamp GIT est un SaaS géré et une GitHub App qui ancre les hachages de commits Git dans la blockchain Bitcoin via le protocole OpenTimestamps. La preuve est vérifiable par quiconque possède le reçu, mais le reçu ne contient jamais votre code.

Pourquoi la vérification est essentielle pour les horodatages de code

Un horodatage ne vaut que par son histoire de vérification. Pour l’antériorité, vous devez prouver qu’un commit spécifique existait avant une date précise. Cette preuve doit fonctionner dans deux directions : elle doit être suffisamment solide pour un tribunal ou un auditeur, et suffisamment privée pour que vous n’exposiez pas de secrets commerciaux simplement pour prouver leur existence.

L’idée centrale est la vérification à divulgation nulle de connaissance : prouver l’existence sans révéler le contenu. Un hachage de commit Git est une empreinte unidirectionnelle de l’état du dépôt. Le hachage seul ne peut pas être inversé pour retrouver le code source. Lorsque ce hachage est ancré dans la blockchain Bitcoin, vous obtenez un enregistrement public et immuable attestant que l’empreinte existait à un moment donné.

Si vous découvrez ce concept, lisez Qu’est-ce que la preuve d’existence pour le code logiciel ?. Cet article se concentre sur le volet vérification : à quoi ressemble une preuve, comment la vérifier et ce que signifient les résultats.

Timestamp GIT automatise le protocole sous-jacent afin que vous n’ayez pas à exécuter de commandes OpenTimestamps ni à gérer manuellement des transactions Bitcoin. Vous installez la GitHub App une seule fois, connectez un dépôt, et chaque commit est regroupé et ancré chaque nuit. La vérification s’effectue ensuite via des badges, des pages de statut publiques et un visualiseur de chaîne de Merkle dans le navigateur.

À quoi ressemble une preuve d’horodatage

Chaque jour ancré produit deux artefacts principaux dans votre dépôt :

• Un fichier manifeste (.txt) qui liste les hachages de commits inclus dans le lot du jour.
• Un fichier de reçu .ots qui contient la preuve OpenTimestamps et les données d’ancrage Bitcoin.

Ces fichiers sont poussés vers une branche dédiée aux horodatages dans votre dépôt ou vers un dépôt miroir. Ils contiennent des hachages de commits et des données d’ancrage — pas de code source, pas de contenu de fichiers, ni de métadonnées de dépôt au-delà de ce qui est nécessaire pour la preuve.

Comme le reçu .ots est public et autonome, toute personne disposant du fichier peut vérifier l’ancrage contre la blockchain Bitcoin. La preuve ne dépend pas d’une base de données privée. Timestamp GIT fournit un vérificateur web qui effectue les vérifications de chaîne de Merkle localement dans votre navigateur, vous permettant ainsi de vérifier sans installer de logiciel et sans exposer quel dépôt vous contrôlez.

Pour rendre la vérification visible, Timestamp GIT prend en charge des badges intégrables pour votre README. Le badge renvoie vers la page de statut publique de votre dépôt. Pour les dépôts privés, l’URL de statut inclut un HMAC chiffré afin que seuls les utilisateurs autorisés puissent consulter le résultat. Le badge lui-même peut afficher le dernier bloc Bitcoin ancré, le nombre total de commits horodatés ou un résumé combiné.

Vérification étape par étape avec Timestamp GIT

Le flux de vérification est conçu pour quelqu’un qui ne souhaite pas apprendre le protocole sous-jacent. Voici le parcours normal.

Étape 1 : Installez la GitHub App Timestamp GIT sur votre dépôt

Il s’agit d’une configuration unique. En mode Standard, la GitHub App lit le hachage du commit HEAD depuis votre dépôt source surveillé. Elle a besoin d’un accès en lecture seule au dépôt source car les permissions GitHub n’exposent pas de niveau d’accès limité au hachage de commit uniquement, et d’un accès en lecture-écriture au dépôt cible où la branche de preuve sera écrite. En mode Enterprise ZK, une courte GitHub Action 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.

Étape 2 : Attendez l’ancrage nocturne

Les hachages de commits sont détectés automatiquement. Chaque nuit, un worker regroupe les hachages en attente, crée des fichiers manifestes, construit un arbre de Merkle, crée des preuves OpenTimestamps à l’aide de calendriers OTS publics et ancre la racine de Merkle dans la blockchain Bitcoin. La confirmation Bitcoin prend généralement environ trois heures après le lot nocturne, donc un commit effectué aujourd’hui est normalement vérifiable le lendemain.

Étape 3 : Utilisez le badge ou la page de statut

Pour les dépôts publics, visitez la page de statut à l’adresse :

https://timestampgit.dev/status/{user}/{repo}

Ce tableau de bord public affiche la longévité de la preuve, la date d’ancrage la plus ancienne, la régularité quotidienne, les données de bloc et de transaction Bitcoin, ainsi qu’un calendrier en carte thermique. Il propose également des liens pour télécharger des rapports d’audit au format CSV et des certificats PDF.

Vous pouvez également interroger directement l’API de statut :

# Dernières informations sur le bloc Bitcoin ancré
curl -s https://timestampgit.dev/api/statusLast/acme/webapp

# Nombre total de commits horodatés
curl -s https://timestampgit.dev/api/statusCount/acme/webapp

# Résumé combiné pour les badges Shields.io
curl -s https://timestampgit.dev/api/statusSummary/acme/webapp

Remplacez acme/webapp par votre utilisateur ou organisation GitHub et le nom du dépôt. Pour les dépôts privés, le point de terminaison authentifié GET /api/badgeLink/{user}/{repo} renvoie les URL de badge et les extraits Markdown avec un HMAC chiffré ajouté.

Étape 4 : Ouvrez la page de vérification pour un jour spécifique

Pour une preuve détaillée, étape par étape, de la chaîne de Merkle, ouvrez :

https://timestampgit.dev/verification/{user}/{repo}/{date}

Cette page exécute le calcul de vérification localement dans votre navigateur. Elle affiche la chaîne de Merkle à plusieurs niveaux depuis votre hachage de commit jusqu’à la racine de Merkle ancrée et le bloc Bitcoin. Comme le calcul est local, le service ne voit pas ce que vous vérifiez.

Étape 5 : Téléchargez les enregistrements formels

Depuis la page de statut ou l’API, vous pouvez télécharger :

• Un registre d’audit CSV pour l’historique complet : GET /api/audit/{user}/{repo}
• Un certificat PDF pour une date spécifique : GET /api/report/{user}/{repo}/{date}

Ces documents sont utiles pour les archives juridiques ou de conformité. Le certificat PDF vous donne un enregistrement lisible par l’humain, tandis que le CSV vous fournit une piste d’audit complète.

Si vous avez besoin des données de vérification sous-jacentes, le point de terminaison GET /api/verify/{user}/{repo}/{date} renvoie les données complètes de la chaîne de Merkle pour une vérification locale.

Interprétation des résultats de vérification et cas particuliers

Une vérification réussie signifie une chose : le hachage du commit a été inclus dans un arbre de Merkle dont la racine a été ancrée dans un bloc Bitcoin spécifique à un moment précis. Une fois ce bloc confirmé, l’horodatage est immuable. Aucune partie — y compris Timestamp GIT — ne peut le modifier ou le falsifier.

Il existe quelques cas particuliers à comprendre.

Ancrages en attente

Juste après un commit, la preuve n’existe pas encore. Timestamp GIT regroupe et ancre les hachages chaque nuit. La confirmation Bitcoin prend normalement environ trois heures après l’exécution du worker nocturne. Pendant cette fenêtre, la page de statut peut afficher le lot comme en attente. Une fois la transaction confirmée, la preuve est immédiatement vérifiable.

Dépôts privés

Pour les dépôts privés, les URL de statut et de vérification publiques ne sont pas ouvertement accessibles. Le système ajoute un HMAC chiffré spécifique à l’instance serveur. Seuls les utilisateurs autorisés disposant de l’URL signée complète peuvent consulter la page de statut ou de vérification. Cela maintient la confidentialité du nom du dépôt et des métadonnées de commit tout en permettant aux auditeurs désignés de vérifier la preuve.

Indépendance vis-à-vis des serveurs Timestamp GIT

La vérification ne nécessite pas que Timestamp GIT reste en ligne. La preuve repose sur les données de la blockchain Bitcoin. Vous pouvez télécharger le fichier .ots et utiliser les outils de vérification OpenTimestamps standard contre la blockchain Bitcoin si vous préférez la méthode manuelle. Le vérificateur de navigateur de Timestamp GIT est la version gérée de cette même vérification.

Fichiers .ots perdus

Le reçu .ots et les fichiers manifestes sont stockés dans la branche dédiée aux horodatages ou dans le dépôt miroir. Si vous perdez une copie locale, retéléchargez-la depuis la branche. La preuve est récupérable depuis le même emplacement Git où le service l’a initialement écrite.

Vérification sans partage de la source : l’avantage zéro connaissance

La plus grande idée reçue sur l’horodatage de code est que le service doit voir votre code pour prouver son existence. Timestamp GIT ne le fait pas.

En mode Standard, la GitHub App lit uniquement le hachage du commit HEAD. Elle ne lit, ne copie ni ne stocke jamais votre code source. En mode Enterprise ZK, la GitHub Action s’exécute sur votre infrastructure et pousse uniquement le hachage vers l’API Timestamp GIT. Le dépôt source n’a besoin d’aucun accès en lecture pour Timestamp GIT dans ce mode. Cela rend le mode Enterprise ZK adapté aux environnements hautement sensibles.

Un tiers — un auditeur, un avocat adverse ou un tribunal — peut vérifier un horodatage sans que vous lui accordiez l’accès au dépôt. Vous fournissez le fichier .ots ou l’URL de vérification signée, et ils peuvent vérifier la preuve contre la blockchain Bitcoin. Ils voient des preuves cryptographiques, pas du code source.

Pour les détails de configuration des deux modes de déploiement, consultez Automatiser l’horodatage de code avec une GitHub App.

FAQ

Puis-je vérifier un horodatage sans rien installer ?

Oui. Timestamp GIT fournit une page de vérification web où vous pouvez utiliser le fichier .ots ou la page de statut publique. Tous les calculs s’effectuent localement dans votre navigateur, donc aucune installation de logiciel n’est requise.

La vérification nécessite-t-elle de partager mon code source ?

Non. La vérification utilise uniquement le hachage du commit et le reçu .ots, qui ne contiennent aucun code source. L’architecture zéro connaissance garantit que votre code reste privé.

Combien de temps faut-il pour qu’un horodatage soit vérifiable ?

Les horodatages sont ancrés chaque nuit, et la confirmation Bitcoin prend généralement environ 3 heures. Une fois confirmée, la preuve est immédiatement vérifiable.

Que se passe-t-il si je perds le fichier de reçu .ots ?

Le fichier .ots est stocké dans une branche dédiée de votre dépôt ou dans un dépôt miroir. Vous pouvez le retélécharger à tout moment depuis cet emplacement.

Conclusion

La vérification est le moment où l’horodatage cryptographique devient utile. Une preuve que vous ne pouvez pas vérifier n’est pas une preuve. Timestamp GIT rend le parcours de vérification pratique : installez la GitHub App une fois, laissez les commits être ancrés chaque nuit, puis utilisez les badges, les pages de statut et la vérification locale dans le navigateur pour démontrer quand votre code a existé — sans jamais partager la source.

Configurez votre premier dépôt sur Timestamp GIT.

Articles connexes

• Qu’est-ce que la preuve d’existence pour le code logiciel ?
• Comment prouver que votre code existait avant un dépôt de brevet
• Horodater les commits Git pour se défendre contre les trolls de brevets
• Automatiser l’horodatage de code avec une GitHub App