Horodater pour les équipes logicielles
Par BlockchainSignMis à jour le
Le contrôle de version vous donne un historique détaillé et une date faible. Les horodatages de commit sont écrits par votre machine et un rebase produira n'importe quel historique vous souhaitez. Pour tout ce qui pourrait servir de preuve, c'est un problème qui vaut son pesant d'argent.
La faille dans votre historique existant
Git enregistre beaucoup de choses avec précision pour l'ingénierie. En tant que preuve, il présente une faiblesse spécifique : les dates sont à écrire par vous.
git commit --date, un rebase interactif, un changement d'horloge — tout cela produit un historique qui semble parfaitement ordinaire et dit ce que vous voulez. C'est acceptable en interne. Face à un adversaire motivé, c'est peu concluant, et la même faiblesse joue contre vous lorsque vous êtes celui qui se défend.
Les horodatages propres à un dépôt hébergé sont meilleurs, mais ils appartiennent à une plateforme, peuvent être perdus avec un compte, et ne sont pas vérifiables indépendamment par quelqu'un de l'extérieur.
Ce qu'il faut ancrer
Les versions (releases). Le hash d'une archive de version ou d'un bundle de dépôt, horodaté à chaque sortie. Cela fournit un record inviolable daté de ce qui a été livré, utile dans une réclamation pour contrefaçon et tout aussi utile pour s'en défendre — prouver que votre version précède le code dont on vous accuse de copie est la même opération à l'envers.
Les états avant divulgation. Avant que le code ne soit envoyé à un client, un auditeur, un acquéreur ou un agent séquestre. Le hash est calculé dans votre navigateur et seul le hash est transmis, ce qui importe quand le code est un secret commercial — voir marque vs droit d'auteur pour le code source pour comprendre pourquoi le secret est souvent la protection qui fait réellement le travail.
Les documents de design et d'architecture. Souvent les artefacts les plus précieux et les moins protégés qu'une équipe possède.
Les instantanés de données. Là où vous devez montrer qu'un jeu de données était dans un état particulier à un moment précis.
Comment faire en pratique
Hashsez l'artefact, pas l'arbre de travail. Le schéma fiable est une archive déterministe :
git archiveougit bundlepour un état de dépôt- Un artefact de build pour une version
- Une archive tar pour un répertoire, avec un ordre reproductible si vous voulez que le hash soit répétable
Puis horodatez ce fichier. Stockez le certificat avec la version, et notez la balise à laquelle il correspond. N'importe qui peut plus tard recréer l'archive, la hasher, et comparer avec le registre.
Pourquoi rien n'est téléchargé
Pour le code propriétaire, l'exigence de confidentialité est absolue, et un service d'horodatage qui veut le fichier est un service que vous ne pouvez pas utiliser.
Ici, le fichier est hashé dans votre navigateur avec l'API Web Crypto et seul le hash SHA-256 de 64 caractères est transmis. Il n'y a aucun point de terminaison qui accepte l'artefact. Si vous préférez générer le hash vous-même, l'outil de hash gratuit le fait localement, et il produit une sortie byte-identique à shasum -a 256.
Ce que cela prouve
Que l'artefact existait à cette date et n'a pas changé. Cela ne prouve pas qui l'a écrit, ce n'est pas un brevet, et cela n'enregistre pas le droit d'auteur — voir preuve d'existence vs preuve de paternité.
Le droit d'auteur sur votre code naît automatiquement. Ce qui vous manque généralement, c'est une date inattaquable, et c'est précisément la faille que cela comble.