Vérifier un téléchargement avec sha256sum sous Linux

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, puis laissez un outil comparer ce hash à celui publié par l’éditeur. sha256sum réalise ces deux étapes : seul, il affiche un digest ; avec -c, il lit une liste de digests et indique quels fichiers correspondent. Ce guide déroule toute la procédure sur un fichier que vous créez, puis modifie volontairement ce fichier afin que vous observiez l’échec au lieu de vous contenter de le lire.

Gardez une phrase à l’esprit pendant toute la procédure. Une somme de contrôle indique si les octets que vous détenez sont ceux qui ont produit le digest. Elle ne dit rien sur l’identité de la personne ou du système qui l’a produit. 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 trouve la limite entre les deux.

Créer un fichier pour s’entraîner

Travaillez dans un répertoire temporaire afin qu’aucune commande ne modifie le reste du système. Toutes les commandes ci-dessous proviennent de GNU coreutils, l’ensemble de commandes de base présent sur tout serveur Ubuntu ou Debian. Rien n’est donc à 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 le digest du fichier. Exécutez à nouveau la commande : la ligne est identique, car le hachage est déterministe. La même entrée produit toujours la même sortie. Modifiez un caractère du fichier et relancez la commande : le digest ne change pas légèrement. Il devient complètement différent, car l’inversion d’un bit de l’entrée inverse environ la moitié des bits de la sortie. Cette propriété permet d’utiliser une chaîne de 64 caractères comme représentante d’une image de 4 GB.

Enregistrez un fichier SHA256SUMS, puis vérifiez-le

Un condensat affiché à l’écran ne sert plus à rien le lendemain. Écrivez-le dans un fichier, au format que sha256sum produit lui-même, afin que l’outil puisse le relire plus tard.

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

sha256sum -c lit chaque ligne de la liste, calcule le condensat du fichier indiqué sur cette ligne et compare les deux condensats. Une exécution correcte affiche une ligne par fichier :

payload.txt: OK

Vérifiez également le code de retour, car un script le lit et ne lit jamais le texte. echo $? affiche 0 après une exécution réussie. Le nom SHA256SUMS est une convention, pas une règle, mais les distributions et la plupart des pages de publication l’utilisent. Utilisez-le également : la personne suivante saura ce que contient le fichier sans devoir l’ouvrir.

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

Cassez maintenant le fichier volontairement. Cette commande écrit un seul octet à l’offset 5 et ne modifie rien d’autre. Le fichier conserve donc sa taille et son nom.

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

conv=notrunc est l’option importante : sans elle, dd tronque le fichier à l’endroit où il s’arrête d’écrire. Vous testeriez alors un type de dommage beaucoup plus évident. La vérification affiche maintenant :

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 digest ne correspond pas à celui de la liste. Restaurez les octets d’origine et vérifiez que la vérification renvoie OK :

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

C’est toute la méthode. Une différence d’un seul octet, à n’importe quel endroit du fichier, produit FAILED. Un téléchargement interrompu par une perte de connexion, un miroir qui fournit la build d’hier, un proxy qui réécrit le fichier pendant son transfert ou un disque qui renvoie un bloc incorrect : tous ces cas aboutissent à la même ligne.

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

Un vrai fichier SHA256SUMS fourni par une distribution répertorie toutes les images que le projet publie, et vous en avez téléchargé une. 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 correspond à un échec différent 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 obtenu le fichier, donc qu’aucune comparaison n’a été effectuée. Lors d’un téléchargement réel, la cause habituelle est le répertoire de travail, car les noms de la liste sont relatifs au répertoire depuis lequel vous exécutez la commande. Accédez au répertoire qui contient le fichier, puis exécutez-la de nouveau. Pour vérifier uniquement les fichiers que vous avez réellement, demandez-le explicitement :

sha256sum --ignore-missing -c SHA256SUMS.all

Cette commande affiche payload.txt: OK et se termine avec le code 0. Si aucun des noms répertoriés n’est présent, --ignore-missing ne réussit pas silencieusement avec zéro fichier. Il indique que no file was verified et se termine avec un code différent de zéro. C’est le comportement attendu, car une vérification réussie qui n’a contrôlé aucun fichier est l’échec que vous ne remarqueriez jamais.

Coller un digest publié sans le lire à l’œil

Comparer à l’œil 64 caractères hexadécimaux est précisément le point faible de cette habitude. Les utilisateurs vérifient les quatre premiers caractères et les quatre derniers, puis considèrent que les valeurs correspondent. C’est exactement la comparaison qu’un attaquant déterminé cherche à exploiter. Laissez plutôt l’outil effectuer la comparaison. Définissez EXPECTED avec le digest copié depuis l’éditeur, en utilisant EXPECTED= suivi de la valeur collée, puis construisez l’unique ligne 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 analysé par -c. Un fichier contenant uniquement un digest ne constitue pas une ligne de checksum. La vérification rejette donc l’ensemble du fichier avec no properly formatted checksum lines found au lieu de deviner quel fichier vous vouliez désigner. Certains projets publient plutôt le format balisé BSD, SHA256 (payload.txt) = suivi du digest. GNU coreutils écrit ce format avec sha256sum --tag payload.txt et le relit avec -c. Vous pouvez donc enregistrer l’un ou l’autre format.

Lorsqu’une vérification se comporte de manière inattendue, examinez directement la liste avec cat -A SHA256SUMS. Cette commande marque la fin de chaque ligne avec $ et affiche les caractères normalement invisibles. Une ligne qui se termine par ^M$ contient un retour chariot ajouté par un éditeur Windows. GNU sha256sum ignore ce caractère final et affiche quand même OK. Une liste CRLF n’est donc pas nécessairement la cause du problème, même si les outils extérieurs à coreutils sont 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 seule chose : les octets présents sur votre disque sont ceux qui ont produit le digest publié. Elle détecte donc toutes les altérations accidentelles. Elle détecte aussi le remplacement négligent d’un fichier par un attaquant qui aurait pu modifier le fichier sur un download mirror, mais pas la page qui publie le digest.

Elle ne prouve rien sur l’auteur du fichier. Un digest décrit des octets, pas des personnes. Si une même page fournit le fichier et le digest, la personne capable de modifier l’un peut modifier l’autre. Dans ce cas, votre ligne OK signifie seulement que le mirror est cohérent avec lui-même. Voici donc la règle qui donne son intérêt à la vérification des sommes de contrôle : récupérez le digest à un autre endroit que le fichier. Par exemple, utilisez le domaine officiel du projet via TLS (transport layer security), tandis que l’image provient d’un mirror ou d’un torrent. L’attaquant doit alors contrôler deux endroits au lieu d’un. Cela ne dit rien non plus de ce que feront ces octets vérifiés lorsque vous les exécuterez. C’est une question distincte à poser pour tout ce qui s’exécute en votre nom, d’un script d’installation à un plugin dsh exécuté avec les permissions de votre agent.

L’algorithme compte également. SHA-256 (secure hash algorithm, sortie de 256 bits) ne présente aucune collision connue en août 2026, ce qui explique pourquoi les éditeurs l’utilisent. MD5 (message digest 5) et SHA-1 ne sont pas suffisamment fiables : il est possible de construire depuis 2004 deux fichiers différents ayant le même digest MD5, et une collision SHA-1 à préfixe choisi a été publiée en 2020. Un fichier MD5SUMS détecte tout de même un téléchargement tronqué, car une corruption aléatoire n’est pas une collision construite. Il ne peut pas empêcher quelqu’un d’essayer de vous tromper. Lorsqu’un projet publie les deux, utilisez la ligne SHA-256.

Quand les signatures prennent le relais

Une signature comble la faille laissée par un digest. L’éditeur signe le fichier de digests avec une clé privée, puis vous le vérifiez avec sa clé publique : gpg --verify SHA256SUMS.asc SHA256SUMS. Si cette vérification réussit, la liste des digests provient bien du détenteur de cette clé. Ensuite, sha256sum -c SHA256SUMS relie le fichier présent sur votre disque à la liste, et la chaîne de confiance remonte de la clé jusqu’aux octets.

Le point faible se déplace vers la clé. Récupérer la clé depuis la même page que celle qui a fourni le fichier permet à l’attaquant de fournir les deux éléments. GnuPG l’indique clairement : lors d’une première vérification, il affiche Good signature avec WARNING: This key is not certified with a trusted signature!. Good signature signifie que les calculs cryptographiques sont cohérents. Cela ne signifie pas que la clé appartient au projet que vous pensez. Obtenez l’empreinte depuis une deuxième source, par exemple la documentation du projet hébergée sur un autre domaine ou un paquet de distribution qui fournit déjà la clé, puis comparez l’empreinte complète au lieu de vous limiter aux huit derniers caractères. C’est la même rigueur que celle exigée par une clé privée SSH, pour la même raison : la clé détermine la confiance, et tout ce qui en dépend en hérite.

Les builds reproductibles vont un cran plus loin. Un digest publié vous lie toujours au binaire produit par une seule machine. Lorsqu’un build est reproductible, n’importe qui peut compiler le même code source et obtenir une sortie identique octet par octet. Des builders indépendants peuvent donc confirmer le digest publié, au lieu de vous demander de faire confiance à un seul serveur. Cette vérification devient plus importante chaque année, car davantage de code arrive par des pipelines automatisés et des patches rédigés par des machines. Décider ce que vous acceptez dans un build relève de la politique, et les politiques open source pour le code assisté par l’IA traitent la même chaîne d’approvisionnement depuis l’autre extrémité.

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

Sur Debian et Ubuntu, apt exécute automatiquement cette chaîne lors de chaque installation. 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 contient une signature de Release, vérifiée avec les clés présentes dans /usr/share/keyrings et /etc/apt/trusted.gpg.d. Lorsque la chaîne est rompue, apt l’indique : 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 absente, ou Hash Sum mismatch lorsque l’index téléchargé ne correspond pas à Release signé. Cela signifie généralement qu’un proxy de cache a fourni un fichier obsolète ou que vous avez interrogé un miroir pendant sa synchronisation.

C’est la référence à utiliser lorsqu’un site de projet vous demande d’envoyer le contenu d’un script de curl directement vers un shell avec un pipe. Rien ne vérifie les octets et vous ne les voyez jamais. Le serveur peut également renvoyer un contenu à un script et un autre à un navigateur, sans vous laisser de copie à examiner ensuite. Téléchargez le fichier avec curl -fsSL <url> -o install.sh, calculez son empreinte, lisez-le avec less, puis exécutez-le seulement après ces vérifications. Cette habitude prend environ vingt secondes. C’est également celle qu’il vaut mieux adopter sur un VPS tout neuf pendant ses dix premières minutes, avant d’installer quoi que ce soit sur le serveur.

Conservez une liste d’empreintes pour les éléments 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 du système ne le surveille. Une liste d’empreintes permet de vérifier ces fichiers à la demande :

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

--quiet n’affiche rien lorsque tous les fichiers correspondent et affiche uniquement les lignes qui ont échoué lorsque certains fichiers ne correspondent pas. Le silence indique donc la réussite, 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 ; seul le code de retour vous renseigne. Appliquez le même modèle à de vrais fichiers avec sha256sum /usr/local/bin/* > ~/local-bin.sha256 pour créer une référence. Les chemins sont enregistrés dans la liste exactement comme vous les avez saisis. Les chemins absolus permettent donc d’effectuer la vérification depuis n’importe quel répertoire.

Sachez ce que cette référence permet réellement de détecter. Elle détecte la modification d’un fichier. Elle ne détecte pas un attaquant qui dispose déjà de root, car cet attaquant peut réécrire inventory.sha256 aussi facilement que le binaire. Conservez la liste hors de la machine si vous voulez qu’elle ait une quelconque valeur. Cela relève de la question plus générale de la confiance que vous accordez réellement à un VPS et des personnes qui peuvent accéder au disque sous-jacent.

FAQ

Un checksum correspondant signifie-t-il que le téléchargement est sûr ?

Non. Cela signifie que les octets que vous avez correspondent au digest auquel vous les avez comparés. Si l’attaquant contrôle la page qui a publié le digest, il publie le digest de son propre fichier, et votre vérification affiche OK. Une correspondance établit uniquement la cohérence. Pour établir la sécurité, il faut vérifier une signature avec une clé obtenue auprès d’une autre source. Le digest n’hérite de cette confiance qu’à ce moment-là.

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

Parce qu’il n’a jamais lu le fichier. La ligne juste au-dessus indique séparément No such file or directory avec le nom recherché. Les noms contenus dans un fichier SHA256SUMS sont relatifs au répertoire depuis lequel vous exécutez la commande. Placez-vous donc dans le répertoire qui contient le téléchargement, puis exécutez à nouveau la commande. Si la liste contient également des fichiers que vous n’avez pas téléchargés, ajoutez --ignore-missing. Un simple FAILED sans open or read correspond à la situation inverse : le fichier a été lu, mais son digest ne correspondait pas.

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

Oui, pour détecter une corruption accidentelle. Un transfert tronqué ou un bloc défectueux sur le disque ne produira pas par hasard un digest MD5 correspondant. Non, face à un attaquant. Il est possible de construire deux fichiers différents ayant le même digest MD5 depuis 2004, et SHA-1 a été compromis par une collision à préfixe choisi en 2020. Utilisez la ligne SHA-256 lorsqu’un projet publie les deux, et considérez un projet qui utilise uniquement MD5 comme le signe d’un ancien processus de publication.

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

sha256sum -c prouve qu’un fichier correspond à un digest. gpg --verify prouve qu’un fichier de digest a été signé par le détenteur d’une clé privée donnée. Ces mécanismes répondent à des questions différentes. Exécutez donc les deux lorsqu’un projet propose les deux. La signature rend la liste des digests fiable, puis la liste des digests rend le fichier téléchargé fiable.

Comment vérifier un fichier avec un digest affiché sur une page web ?

Ne comparez pas les caractères à l’œil. Enregistrez le digest et le nom du fichier sur une seule ligne, en les séparant par deux espaces, puis exécutez sha256sum -c sur ce fichier et lisez le OK ou le FAILED qu’il affiche. 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.