Vérifier l'intégrité d'un fichier avec sha256sum

Vérifier un téléchargement avec une somme de contrôle en deux minutes

Pour vérifier un téléchargement avec une somme de contrôle, calculez le hash du fichier reçu et laissez un outil le comparer à celui publié par l'éditeur. sha256sum effectue les deux étapes : seul, il affiche une empreinte, et avec -c, il lit une liste d'empreintes et indique quels fichiers correspondent. Ce guide exécute la procédure complète sur un fichier que vous créez, puis altère volontairement ce fichier pour que vous observiez l'échec au lieu de simplement le lire.

Gardez une phrase à l'esprit tout au long de ce guide. Une somme de contrôle vous indique si les octets que vous possédez sont ceux qui ont généré l'empreinte, mais elle ne vous dit rien sur l'identité de l'auteur. Cette seconde question nécessite une signature et une clé de confiance. La dernière partie de ce guide montre précisément où se situe la limite entre les deux.

Créer un fichier pour s'exercer

Travaillez dans un répertoire temporaire afin de ne pas affecter le reste du système. Chaque commande ci-dessous provient des GNU coreutils, le jeu de commandes de base présent sur tout serveur Ubuntu ou Debian ; il n'y a donc rien à installer.

mkdir -p ~/checksum-demo
cd ~/checksum-demo
printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum payload.txt

Vous obtenez une ligne : 64 caractères hexadécimaux, deux espaces, puis le nom du fichier. Ces 64 caractères constituent l'empreinte (digest) du fichier. Exécutez à nouveau la commande et la ligne sera identique, car le hachage est déterministe : une même entrée produit toujours la même sortie. Modifiez un seul caractère du fichier et relancez la commande : l'empreinte ne change pas légèrement. Elle semble totalement différente, car l'inversion d'un seul bit en entrée modifie environ la moitié des bits en sortie. C'est cette propriété qui permet à une chaîne de 64 caractères de servir de substitut fiable à une image de 4 Go.

Enregistrer un fichier SHA256SUMS, puis le vérifier

Un hash affiché à l'écran est inutile le lendemain. Écrivez-le dans un fichier, en utilisant le format que sha256sum génère lui-même, afin que l'outil puisse le relire ultérieurement.

sha256sum payload.txt > SHA256SUMS
cat SHA256SUMS
sha256sum -c SHA256SUMS

sha256sum -c lit chaque ligne de la liste, calcule le hash du fichier mentionné sur cette ligne et compare les deux empreintes. Une exécution réussie affiche une ligne par fichier :

payload.txt: OK

Vérifiez également le code de retour, car un script lit cette valeur et ne lit jamais le texte. echo $? affiche 0 après une exécution sans erreur. Le nom SHA256SUMS est une convention plutôt qu'une règle, mais les distributions et la plupart des pages de release l'utilisent ; utilisez-le donc également pour que la personne suivante sache ce que contient le fichier sans avoir à l'ouvrir.

Modifier un octet et observer l'échec de la vérification

Corrompez maintenant le fichier volontairement. Cette commande écrit un seul octet à l'offset 5 sans modifier le reste, préservant ainsi la longueur et le nom du fichier.

printf 'X' | dd of=payload.txt bs=1 seek=5 conv=notrunc status=none
cat payload.txt
sha256sum -c SHA256SUMS

conv=notrunc est le flag déterminant : sans lui, dd tronque le fichier à l'endroit où l'écriture s'arrête, ce qui vous amènerait à tester un type de dommage bien plus évident. La vérification affiche désormais :

payload.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

echo $? affiche 1. FAILED signifie que le fichier a été lu et que son empreinte ne correspond pas à celle présente dans la liste. Rétablissez les octets d'origine et confirmez que la vérification renvoie OK :

printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum -c SHA256SUMS

C'est là toute la procédure. Un seul octet de différence, n'importe où dans le fichier, produit FAILED. Un téléchargement interrompu par une connexion perdue, un miroir distribuant une version obsolète, un proxy ayant réécrit le fichier durant le transit, ou un disque ayant renvoyé un bloc défectueux : tous aboutissent à ce même résultat.

Lorsque la liste mentionne un fichier que vous n'avez pas téléchargé

Un fichier SHA256SUMS authentique provenant d'une distribution liste toutes les images que le projet publie, et vous en avez téléchargé une seule. Reproduisez cette situation ici.

printf 'a second file\n' > notes.txt
sha256sum payload.txt notes.txt > SHA256SUMS.all
rm notes.txt
sha256sum -c SHA256SUMS.all

payload.txt: OK
sha256sum: notes.txt: No such file or directory
notes.txt: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

FAILED open or read est une erreur différente de FAILED, et les confondre fait perdre du temps. FAILED signifie que les octets sont incorrects. FAILED open or read signifie que sha256sum n'a jamais reçu le fichier, donc aucune comparaison n'a eu lieu. Lors d'un téléchargement réel, la cause habituelle est le répertoire de travail, car les noms dans la liste sont relatifs à l'endroit où vous exécutez la commande. Placez-vous dans le répertoire contenant le fichier et relancez la commande. Pour ne vérifier que ce que vous possédez réellement, demandez-le explicitement :

sha256sum --ignore-missing -c SHA256SUMS.all

Cela affiche payload.txt: OK et se termine avec un code 0. Si aucun des noms listés n'est présent, --ignore-missing ne réussit pas silencieusement sur zéro fichier. Il signale que no file was verified et se termine avec un code différent de zéro, ce qui est le comportement attendu, car une validation qui n'a rien vérifié est une erreur que vous ne remarqueriez jamais.

Coller un digest publié sans vérification visuelle

Comparer 64 caractères hexadécimaux à l'œil nu est l'endroit précis où cette habitude échoue. Les utilisateurs vérifient les quatre premiers et les quatre derniers caractères et concluent à une correspondance, ce qui est exactement la comparaison qu'un attaquant déterminé anticipe. Laissez l'outil effectuer la comparaison. Définissez EXPECTED sur le digest copié depuis l'éditeur, en utilisant EXPECTED= suivi de la valeur collée, puis construisez la ligne unique attendue par -c :

printf '%s  %s\n' "$EXPECTED" payload.txt > payload.sha256
cat payload.sha256
sha256sum -c payload.sha256

Deux espaces séparent le digest du nom de fichier, c'est pourquoi la chaîne de format en contient deux. C'est le format écrit par sha256sum et celui analysé par -c. Un fichier contenant uniquement un digest n'est pas une ligne de checksum valide ; la vérification rejette donc tout le fichier avec no properly formatted checksum lines found au lieu de deviner le fichier visé. Certains projets publient plutôt le format tagué BSD, SHA256 (payload.txt) = suivi du digest. Les GNU coreutils écrivent ce format avec sha256sum --tag payload.txt et le lisent avec -c, les deux formats sont donc acceptables pour la sauvegarde.

Lorsqu'une vérification se comporte de manière inhabituelle, examinez la liste elle-même avec cat -A SHA256SUMS, qui marque la fin de chaque ligne avec $ et affiche les caractères normalement invisibles. Une ligne se terminant par ^M$ a récupéré un retour chariot provenant d'un éditeur Windows. Le sha256sum de GNU ignore ce caractère final et affiche tout de même OK ; une liste CRLF ne bloque donc pas votre vérification, bien que les outils extérieurs aux coreutils soient moins tolérants. Normalisez la copie que vous conservez avec tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

Que prouve une somme de contrôle, et que ne prouve-t-elle pas ?

Une somme de contrôle prouve une chose : les octets présents sur votre disque sont bien ceux qui ont généré l'empreinte publiée. Cela couvre totalement les dommages accidentels. Cela couvre également un attaquant négligent qui aurait remplacé le fichier sur un miroir de téléchargement, mais qui n'aurait pas pu modifier la page publiant l'empreinte.

Elle ne prouve rien quant à l'auteur. Une empreinte est une donnée relative aux octets, pas une donnée relative aux personnes. Si une même page sert à la fois le fichier et l'empreinte, alors quiconque peut modifier l'un peut modifier l'autre, et votre ligne OK signifie seulement que le miroir est cohérent avec lui-même. Voici donc la règle qui rend l'utilisation des sommes de contrôle pertinente : récupérez l'empreinte à un endroit différent de celui où vous avez récupéré le fichier. Le domaine propre du projet via TLS (transport layer security), alors que l'image provient d'un miroir ou d'un torrent, par exemple. Désormais, un attaquant doit contrôler deux endroits au lieu d'un.

L'algorithme compte aussi. SHA-256 (secure hash algorithm, 256-bit output) ne présente aucune collision connue en août 2026, c'est pourquoi les éditeurs l'utilisent. MD5 (message digest 5) et SHA-1 ne sont plus fiables : deux fichiers différents ayant la même empreinte MD5 peuvent être construits depuis 2004, et une collision SHA-1 par préfixe choisi a été publiée en 2020. Un fichier MD5SUMS permet toujours de détecter un téléchargement tronqué, car une corruption aléatoire n'est pas une collision intentionnelle. Il ne peut toutefois pas arrêter quelqu'un qui cherche à vous tromper. Lorsqu'un projet publie les deux, utilisez la ligne SHA-256.

Quand les signatures prennent le relais

Une signature comble la lacune laissée par une empreinte. L'éditeur signe le fichier d'empreintes avec une clé privée, et vous le vérifiez avec sa clé publique : gpg --verify SHA256SUMS.asc SHA256SUMS. Si la vérification réussit, la liste des empreintes provient bien du détenteur de cette clé. Ensuite, sha256sum -c SHA256SUMS lie le fichier présent sur votre disque à cette liste, et la chaîne de confiance s'établit depuis la clé jusqu'aux octets eux-mêmes.

Le point faible se déplace vers la clé. Récupérer la clé sur la même page que celle ayant servi à télécharger le fichier donne les deux parties à un attaquant. GnuPG est transparent à ce sujet, et une première vérification affiche Good signature avec WARNING: This key is not certified with a trusted signature!. Good signature signifie que les mathématiques sont valides. Cela ne signifie pas que la clé appartient au projet que vous visez. Récupérez l'empreinte (fingerprint) depuis une seconde source, comme la documentation du projet sur un domaine différent ou un paquet de distribution qui contient déjà la clé, et comparez l'empreinte complète plutôt que les huit derniers caractères. C'est la même prudence qu'une clé privée SSH mérite, pour la même raison : la clé constitue la décision de confiance, et tout ce qui en dépend en hérite.

Les builds reproductibles poussent cette idée un peu plus loin. Une empreinte publiée vous lie toujours à un binaire généré par une seule machine. Lorsqu'un projet est reproductible, n'importe qui peut compiler la même source et obtenir un résultat identique octet par octet. Des tiers indépendants peuvent ainsi confirmer l'empreinte publiée au lieu de vous demander de croire aveuglément un serveur. Cela devient chaque année plus important, à mesure que le code arrive via des pipelines automatisés et des correctifs générés par des machines. Décider ce que vous acceptez dans un build est une question de politique, et les politiques open source pour le code assisté par IA travaillent sur la même chaîne d'approvisionnement en partant de l'autre extrémité.

Votre gestionnaire de paquets s'en charge déjà

Sur Debian et Ubuntu, apt exécute cette chaîne à chaque installation sans intervention de votre part. L'index des paquets contient une empreinte SHA-256 pour chaque fichier .deb. Le fichier Release contient les empreintes de ces fichiers d'index, et InRelease porte une signature sur Release, vérifiée par rapport aux clés présentes dans /usr/share/keyrings et /etc/apt/trusted.gpg.d. Lorsque la chaîne est rompue, apt le signale : The following signatures couldn't be verified because the public key is not available: NO_PUBKEY lorsqu'une clé de dépôt tiers est manquante, ou Hash Sum mismatch lorsque l'index récupéré ne correspond pas au fichier Release signé, ce qui signifie généralement qu'un proxy de cache a servi un fichier obsolète ou que vous avez accédé à un miroir en cours de synchronisation.

C'est la norme de référence lorsqu'une page d'accueil de projet vous demande de rediriger un script depuis curl directement dans un shell. Rien ne vérifie les octets et vous ne les voyez jamais. Le serveur peut également renvoyer un contenu différent selon qu'il s'adresse à un script ou à un navigateur, et vous n'avez aucune copie à inspecter par la suite. Téléchargez le fichier avec curl -fsSL <url> -o install.sh, calculez son empreinte, lisez-le avec less, et exécutez-le seulement après. Cette habitude prend environ vingt secondes, et c'est la même qu'il convient d'adopter sur un VPS tout neuf dans ses dix premières minutes, avant d'installer quoi que ce soit d'autre sur la machine.

Maintenir une liste d'empreintes pour les fichiers installés manuellement

Les paquets installés par apt sont suivis. Un binaire copié dans /usr/local/bin ne l'est pas, et aucun mécanisme système ne le surveille. Une liste d'empreintes permet de transformer cela en un élément vérifiable à la demande :

printf 'a second file\n' > notes.txt
sha256sum *.txt > inventory.sha256
sha256sum -c --quiet inventory.sha256

--quiet n'affiche rien lorsque chaque fichier correspond, et n'affiche que les lignes en échec en cas de discordance ; le silence est donc signe de succès et echo $? le confirme avec 0. C'est la forme à utiliser dans une tâche planifiée. --status va plus loin et n'affiche absolument rien, ne laissant que le code de sortie. Appliquez le même modèle aux fichiers réels avec sha256sum /usr/local/bin/* > ~/local-bin.sha256 pour obtenir une référence. Les chemins sont stockés dans la liste exactement tels que vous les avez saisis ; utilisez donc des chemins absolus pour que la vérification fonctionne depuis n'importe quel répertoire.

Soyez conscient de la valeur de cette référence. Elle détecte un fichier modifié. Elle ne détecte pas un attaquant ayant déjà obtenu les privilèges root, car cet attaquant peut réécrire inventory.sha256 aussi facilement qu'il a réécrit le binaire. Conservez la liste hors de la machine si vous voulez qu'elle ait une réelle valeur, ce qui fait partie de la question plus large de quel niveau de confiance accorder à un VPS et de qui d'autre peut accéder au disque sous-jacent.

FAQ

Une somme de contrôle identique signifie-t-elle que le téléchargement est sûr ?

Non. Cela signifie simplement que les octets que vous possédez correspondent à l'empreinte avec laquelle vous les avez comparés. Si un attaquant contrôle la page qui publie l'empreinte, il publiera l'empreinte de son propre fichier et votre vérification affichera OK. Une correspondance est une preuve de cohérence. Une preuve de sécurité nécessite une signature vérifiée par une clé obtenue via une source différente ; c'est seulement à cette condition que l'empreinte hérite de cette confiance.

Pourquoi sha256sum -c affiche-t-il FAILED open or read ?

Parce que le fichier n'a pas été lu. Une ligne distincte juste au-dessus indique No such file or directory avec le nom recherché. Les noms contenus dans un fichier SHA256SUMS sont relatifs au répertoire dans lequel vous exécutez la commande. Déplacez-vous dans le répertoire contenant le téléchargement et relancez la commande. Si la liste mentionne également des fichiers que vous n'avez pas téléchargés, ajoutez --ignore-missing. Un simple FAILED sans open or read indique la situation inverse : le fichier a été lu, mais son empreinte ne correspond pas.

MD5 est-il suffisant pour vérifier un téléchargement ?

Pour des dommages accidentels, oui. Un transfert tronqué ou un bloc disque défectueux ne produira pas par hasard une empreinte MD5 identique. Contre un attaquant, non. Deux fichiers différents possédant la même empreinte MD5 peuvent être construits depuis 2004, et SHA-1 a été vulnérable à une collision par préfixe choisi en 2020. Utilisez la ligne SHA-256 lorsqu'un projet publie les deux, et considérez un projet utilisant uniquement MD5 comme le signe d'un processus de publication obsolète.

Quelle est la différence entre sha256sum -c et gpg --verify ?

sha256sum -c prouve qu'un fichier correspond à une empreinte. gpg --verify prouve qu'un fichier d'empreintes a été signé par le détenteur d'une clé privée spécifique. Ils répondent à des questions différentes, exécutez donc les deux lorsqu'un projet les propose. La signature rend la liste d'empreintes fiable, et la liste d'empreintes rend ensuite le fichier téléchargé fiable.

Comment vérifier un fichier par rapport à une empreinte affichée sur une page web ?

Ne comparez pas les caractères à l'œil nu. Enregistrez l'empreinte et le nom du fichier sur une seule ligne, séparés par deux espaces, puis exécutez sha256sum -c sur ce fichier et lisez le OK ou FAILED affiché. Construire la ligne avec printf '%s %s\n' évite les erreurs de formatage qui font que sha256sum rejette le fichier avec no properly formatted checksum lines found.