Outils de développement · Calculateur de hachage SHA
Adressage de contenu : comment Git, Docker et npm utilisent les résumés SHA comme noms
· Contexte
sha-256 menu fixe cryptographie flux de travail du développeur
Les commits Git, les résumés d'images de conteneur et les chaînes d'intégrité des fichiers de verrouillage ont tous la même idée : nommer les données par leur hachage. Cet article explique l'adressage du contenu et ce que chaque écosystème en retire.
Le sha256 : dans votre docker pull – qu'est-ce que cette chaîne et pourquoi elle ne change jamais pour la même image
Les systèmes de contrôle de version, les environnements d'exécution de conteneurs et les gestionnaires de packages utilisent tous la même idée de dénomination : un fichier ou une collection d'octets est nommé par son résumé SHA. Dans Git, l'identifiant 40-character SHA-1 d'un commit (ou 64-character SHA-256 dans les référentiels modernes) est calculé à partir du contenu du commit : l'arborescence, l'auteur, l'horodatage et le message. Modifiez un seul octet et le SHA change. Dans Docker, chaque résumé de couche est un hachage SHA-256 du contenu de la couche, et le résumé d'image est calculé à partir du manifeste. Dans npm et d'autres gestionnaires de packages, les champs d'intégrité stockent les résumés SHA-512 des archives tar pour vérifier les téléchargements. L'adressage de contenu signifie que le nom dépend uniquement des octets, et non d'une base de données centrale ou d'un horodatage.
L'avantage est l'immuabilité au sein de chaque système. Un git commit SHA-256:abc... fera toujours référence au même arbre et au même message car le hachage détermine l'identité. Si quelqu'un prétend avoir un commit différent avec le même SHA, il prétend que les mêmes octets produisent deux hachages différents, ce qui brise la cryptographie. La déduplication devient automatique : deux fichiers avec des octets identiques produisent le même résumé, de sorte que les systèmes de stockage peuvent stocker les octets une fois et les référencer deux fois. La vérification de l'intégrité devient aussi simple que de recalculer le résumé et de le comparer : si les octets ont été modifiés en transit ou au repos, le résumé ne correspond plus.
Nommer les données par leur hachage : l'idée de l'adressage du contenu et pourquoi cela rend la déduplication et l'intégrité gratuites
Git stocke les objets (commits, arbres, blobs et balises) saisis par leur résumé SHA. La commande `git cat-file` prend un ID d'objet et récupère les octets. Le magasin d'objets est adressé par contenu : vous effectuez une demande par résumé, et non par emplacement ou par nom. Lorsque vous clonez un référentiel, git vérifie chaque objet en recalculant son résumé et en le comparant au résumé contenu dans le transfert. La transition de SHA-1 à SHA-256 est progressive ; les référentiels peuvent prendre en charge les deux pour des raisons de compatibilité. Le format sur disque stocke le type d'objet, sa taille et les octets compressés. Le résumé est calculé sur la forme canonique non compressée.
Les référentiels Git modernes peuvent utiliser SHA-256, et la transition est en cours car les collisions SHA-1 sont désormais pratiques (démontrées dans 2017 et affinées dans 2020). Un commit dans un référentiel utilisant SHA-256 a un identifiant hexadécimal de 64 caractères au lieu de 40. La commande `git hash-object` calcule le SHA d'un blob (contenu du fichier) sans le stocker ; `git commit-tree` calcule le SHA d'une arborescence et d'un message. Les deux opérations sont déterministes : les mêmes octets produisent toujours le même résumé. C'est ainsi que GitHub et d'autres forges peuvent afficher les SHA de validation de manière cohérente : ils calculent le même résumé que celui calculé par le clone de l'auteur.
Git utilise des objets adressés par contenu et cet outil peut reproduire des résumés de texte ; les détails de la migration nécessitent des sources spécifiques à Git
Les images Docker sont construites en couches, où chaque couche est un delta du système de fichiers (modifications par rapport à la couche précédente). La spécification d'image OCI définit comment calculer le résumé d'une couche et le résumé du manifeste d'image. Le résumé de couche est le SHA-256 du fichier tar compressé contenant les fichiers de couche. Le manifeste est un document JSON répertoriant les couches, leurs résumés et métadonnées. Le résumé de l'image est le SHA-256 du manifeste JSON lui-même. Lorsque vous extrayez une image à l'aide d'une balise telle que `latest`, le registre recherche la balise et renvoie le résumé du manifeste. Vous pouvez ensuite extraire directement le résumé, en vous assurant d'obtenir exactement les mêmes octets (toutes les couches et métadonnées) à chaque fois.
La commande `docker inspect` sur une image locale affiche son résumé. L'exécution de la même image à partir de la même balise sur deux machines produit le même résumé si le registre contient toujours cette balise pointant vers le même manifeste. L'adressage de contenu rend les chaînes d'approvisionnement d'images vérifiables : un pipeline CI/CD peut vérifier que l'image qu'il a déployée correspond au résumé dans le journal de build, et un scanner de sécurité peut signaler toutes les images connues pour avoir une vulnérabilité spécifique par leur résumé plutôt que par balise, qui peut se déplacer.
Conteneurs — Manifestes OCI et résumés de couches, et pourquoi une balise peut se déplacer mais pas un résumé
Les gestionnaires de packages utilisent des résumés pour vérifier les téléchargements contre toute falsification ou corruption. Dans npm, le fichier `package-lock.json` comprend un champ `integrity` pour chaque dépendance, contenant un hachage (généralement SHA-512) et l'encodage (généralement base64). Lorsque npm télécharge une archive tar, il recalcule le hachage et compare. Si les hachages ne correspondent pas, l'installation échoue. Go utilise un fichier `go.sum` avec une structure similaire : chemin du module, version et SHA-256 de la source du module. Cargo utilise des sommes de contrôle dans `Cargo.lock`. Le principe est identique : le résumé est calculé une fois lors de la première résolution de la dépendance, et vérifié à chaque installation ultérieure.
La vérification de l'intégrité ne nécessite pas de télécharger le package vers une autorité signataire ni de stocker les signatures séparément. Le résumé EST le contrôle d’intégrité. Pour une assurance maximale, les projets utilisent `go.sum` qui est signé par le système de transparence du projet Go, ou l'intégrité npm combinée à d'autres vérifications, mais le cas de base est simple : l'éditeur calcule le résumé une fois, l'enregistre dans le fichier de verrouillage et les outils côté consommateur vérifient que les octets téléchargés correspondent.
Les codages d'intégrité des packages varient ; seules les sorties SHA prises en charge par cette calculatrice sont affirmées ici
Les mêmes octets via le même algorithme produisent toujours le même résumé, quelle que soit la provenance des octets. La construction locale d'un commit par un développeur produit le même SHA-256 qu'un système CI/CD extrayant la même révision à partir du même référentiel. Cette reproductibilité est la raison pour laquelle l'adressage de contenu fonctionne : vous pouvez vérifier un artefact sans faire confiance au mécanisme de livraison. Le résumé devient un engagement cryptographique : la modification d’un seul octet l’invalide.
La distribution du résumé séparément (avant de distribuer l'artefact) protège contre les modifications en cours. Une page Web publiée avant la publication peut afficher « attendre SHA-256:abc » et les utilisateurs peuvent ensuite vérifier les téléchargements par rapport à celle-ci. Un commit git publié dans un référentiel public est un engagement sur les octets ; le résumé le prouve.
Exemple concret : suivre un blob à partir d'octets pour le digérer jusqu'au nom qu'un outil utilise pour celui-ci
Différents systèmes codent leurs résumés différemment. Git utilise par défaut des caractères hexadécimaux minuscules (caractères hexadécimaux 40 ou 64). Docker utilise le format `sha256:` suivi de hex. npm et Go utilisent base64 dans les champs d'intégrité. Les octets sont les mêmes ; seule la représentation diffère. Un résumé SHA-256 sur "abc" est toujours le même 256 bits, mais vous pouvez le voir comme une chaîne hexadécimale de 64 caractères, une chaîne base64 de 44 caractères ou une étiquette comme `sha256:` suivie de l'une ou l'autre. La conversion entre les encodages s'effectue sans perte ; le résumé a la même valeur dans chaque représentation.
Comprendre l'encodage est important lors de la comparaison des résumés entre les outils. Si Git imprime un résumé hexadécimal et qu'un outil affiche base64, vous devez convertir une représentation en l'autre pour vérifier qu'elles correspondent. Le calculateur de hachage SHA de ToolAcre affiche à la fois en hexadécimal et en base64 pour chaque résumé, ce qui facilite la conversion ou les références croisées avec d'autres systèmes.
Ce que cela ne couvre pas : les codages spécifiques utilisés par chaque outil (hex versus base64), abordés dans un article séparé
L'adressage de contenu n'est pas spécifique à la cryptographie, bien que les hachages cryptographiques le rendent sécurisé. Une somme de contrôle CRC32 traite également les données, mais les collisions CRC32 sont courantes et des collisions peuvent être fabriquées ; ce référentiel ne marque pas SHA-256 comme cassé, tandis que CRC32 n'est pas proposé comme primitive d'intégrité contradictoire. Le choix de l'algorithme de hachage est important pour la sécurité : SHA-256 est la norme moderne pour les systèmes qui ont besoin d'une protection d'intégrité contre les adversaires. SHA-1 est uniquement un héritage (Git et d'autres migrent). Choisir le bon algorithme est une décision distincte du choix de l’adressage de contenu comme schéma de dénomination.
L'adressage de contenu combiné aux hachages cryptographiques constitue le fondement de l'intégrité de la chaîne d'approvisionnement dans les logiciels modernes. Chaque paquet que vous installez, chaque conteneur que vous exécutez et chaque commit que vous extrayez peuvent être vérifiés comme étant les octets prévus par l'éditeur d'origine, sans compter sur un transfert sécurisé (bien que le transfert sécurisé reste une bonne pratique).
À retenir : le hachage est l'identité – le calculateur de hachage ToolAcre SHA vous permet de calculer les mêmes résumés sur lesquels ces systèmes s'appuient
L'adressage du contenu est indépendant de l'encodage, de l'emplacement de stockage ou du mécanisme de transfert. Les mêmes octets produisent le même résumé, qu'ils soient stockés localement, dans un CDN, dans un registre ou transmis via HTTP ou HTTPS sécurisé. Le résumé est un engagement cryptographique sur les octets, et sa vérification ne nécessite que les octets et l'algorithme, pas un service externe. C'est pourquoi l'adressage de contenu permet une vérification hors ligne : vous pouvez télécharger un fichier sur un canal non fiable, vérifier le résumé et savoir si les octets sont authentiques.
Le calculateur de hachage ToolAcre SHA vous permet de calculer les mêmes résumés sur lesquels s'appuient ces systèmes. Collez une chaîne ou regardez un fichier, exécutez la calculatrice et consultez les résumés SHA-256, SHA-384 et SHA-512 que Docker, Git, npm et d'autres outils utilisent en interne. Comparez votre résumé calculé avec celui de la source d'origine pour vérifier que les octets n'ont pas été modifiés. La calculatrice hache le texte UTF-8 que vous collez ; il ne hache pas les fichiers ou les éléments de clé, donc la frontière entre ce qu'il peut hacher (saisie de texte) et ce qu'il ne peut pas (fichiers binaires, clés cryptographiques dans leurs formes codées) est claire et documentée.