Pourquoi un hash ne suffit pas à expliquer l’origine d’un logiciel

Une empreinte répond à une question précise

Vous téléchargez une archive et recalculez son empreinte. Si elle correspond à la valeur de référence selon le même algorithme et les mêmes règles, vous avez établi une correspondance avec cette référence.

Mais d’où vient la valeur de référence ? Si un fichier et son empreinte sont remplacés ensemble, leur comparaison peut réussir. La fiabilité du canal ou du document portant la référence compte donc autant que le calcul lui-même.

La signature protège la référence

Une signature permet de détecter la modification du document signé et d’en vérifier le lien à une clé. Le destinataire doit encore avoir une raison d’approuver cette clé.

Cette signature ne raconte pas davantage l’histoire du build si le document ne contient qu’un hash. Elle protège exactement la déclaration signée, ni plus ni moins.

La provenance ajoute le contexte

Une provenance de build décrit les informations enregistrées sur la fabrication. Les entrées déclarées, les commandes et les résultats aident à examiner pourquoi deux compilations ont produit des artefacts différents.

Prenons deux archives portant le même numéro de version. Leurs empreintes diffèrent. Le hash révèle cet écart ; une provenance peut aider à l’expliquer en montrant un changement d’entrée, d’étape ou de contexte enregistré. Elle n’explique que ce qui appartient effectivement au périmètre capturé.

Le reçu assemble ces informations

Continuum Attest enregistre des empreintes et des étapes dans un reçu qui peut être signé. Le format du reçu définit les règles de calcul et de signature. Utilisez les contrôles du format concerné : une empreinte de fichier générique ne remplace pas nécessairement une empreinte calculée sur un ensemble déclaré.

Pour organiser la comparaison depuis une autre machine, lisez Peut-on vérifier un logiciel sans faire confiance à la plateforme qui l’a construit ?, puis le guide de vérification hors ligne.