Comment horodater une sortie de logiciel

Le contrôle de versions offre un historique excellent mais une date fragile. Ancrer une version résout ce second problème en environ une minute par version.

Pourquoi les dates Git ne suffisent pas

Les horodatages des commits sont écrits par la machine qui effectue le commit. Un rebase interactif, un changement d'heure ou l'indicateur --date standard peuvent produire n'importe quel historique, et le résultat semble tout à fait normal.

C'est acceptable en interne. En tant que preuve, c'est faible, et cette faiblesse joue dans les deux sens : elle est également peu utile lorsque vous défendez votre position face à une revendication plutôt que lorsque vous en faites une.

Les propres horodatages d'une plateforme hébergée sont meilleurs, mais ils appartiennent à la plateforme, disparaissent avec le compte, et un tiers ne peut pas les vérifier indépendamment.

Ce qu'il faut ancrer

Pas l'arbre de travail. Un artefact déterministe dont vous pouvez reproduire les octets plus tard :

git archive --format=tar.gz -o release-v1.4.0.tar.gz v1.4.0

ou un bundle, qui capture l'historique ainsi que le contenu :

git bundle create release-v1.4.0.bundle v1.4.0

ou la sortie de build elle-même, si votre build est reproductible.

Ensuite, hashsez ce fichier et horodatez le hash.

Les étapes

1. Créez l'artefact à partir du tag, pas depuis votre répertoire de travail.
2. Hashsez-le — shasum -a 256, ou l'outil en ligne de commande, qui produit une sortie identique.
3. Horodater le hash. Le fichier est hashé dans votre navigateur et seul le hash est transmis, ce qui importe lorsque le code est propriétaire.
4. Stockez le certificat avec la version, et notez à quel tag il correspond.
5. Conservez l'artefact, octet pour octet. Le régénérer plus tard pourrait ne pas reproduire des octets identiques, car les formats d'archive stockent les horodatages et l'ordre.

Ce dernier point piège souvent les gens. Une archive tar.gz reconstruite à partir du même tag sur une autre machine est fréquemment un fichier différent. Gardez celui que vous avez hashé.

Rendre cela reproductible, si vous voulez sauter l'étape 5

Des archives déterministes sont réalisables avec des efforts — temps de modification fixes, entrées triées, niveau de compression épinglé. Si votre build est déjà reproductible, hasher la sortie signifie que n'importe qui peut le régénérer et le vérifier indépendamment, ce qui est plus solide que de demander aux autres de faire confiance à votre copie stockée.

Si ce n'est pas le cas, conserver l'artefact est tout à fait raisonnable et bien moins coûteux que de rendre le build déterministe uniquement à cette fin.

Ce que cela vous apporte

La signature et l'horodatage composent bien ensemble et répondent à des questions différentes. Un tag signé prouve qui l'a créé et que le contenu n'a pas été modifié ; la date de la signature reste celle que la machine du signataire a indiquée. L'horodatage fixe le temps indépendamment. Faites les deux pour les versions importantes.

Quand cela vaut le coup

Versions publiques où la date pourrait importer dans une question de licence ou de contrefaçon.

Avant un audit, un dépôt en escrow ou une acquisition — un enregistrement daté de ce qui a exactement été remis.

Avant de divulguer du code à un client ou partenaire, ce qui est aussi le moment où le code est le plus exposé comme secret commercial. Voir marque déposée vs droit d'auteur pour le code source.

Quand vous utilisez une licence permissive et souhaitez un enregistrement de votre version antérieur aux revendications d'un fork.

Pas nécessaire pour chaque commit. L'idée est d'avoir un petit nombre d'ancres datées autour des états qui pourraient nécessiter une défense, pas de cérémonial pour le travail ordinaire.

Pour la version plus large de cet argument, voir l'horodatage blockchain pour les équipes logicielles.