Bonjour, j'ai une interrogation de néophytes.
J'ai lu à plusieurs endroit qu'il fallait vérifier l'intégrité d'un fichier. Par exemple ici, on peut lire
Lorsque l’on télécharge un fichier d’ISO d’installation d’un OS ou un logiciel, ce dernier pourrait être corrompu par rapport à son original pour plusieurs raisons :
-erreur de lecture/écriture lors du téléchargement
-code malveillant introduit par des hackers sur le fichier mis à disposition
-etc.Aussi, pour vérifier qu’un fichier correspond bien à celui attendu, les éditeurs et développeurs peuvent mettre à disposition sur leur site (parfois dans un fichier) des empreintes des hachages des fichiers originaux.
Pour le cas d'une erreur de lecture/écriture, je comprends bien l'intérêt. En revanche, pour se prévenir de l'introduction de code malveillant, je ne comprends pas.
En effet, imaginons que des hackers aient pris le contrôle du serveur pour pouvoir y déposer une image ISO contenant du code malveillant, qu'est ce qui les empêcherait de générer une nouvelle empreinte de hachages correspondant à cette nouvelle ISO ?
Merci de m'éclairer sur ce dernier point.
# Impossible de vérifier si compromis
Posté par _kaos_ . Évalué à 3. Dernière modification le 26 février 2021 à 15:14.
Salut,
Rien ne les en empêche, et t'as un plus gros problème à régler
Matricule 23415
# pour les distrib linux
Posté par fearan . Évalué à 6.
tu as souvent plusieurs serveurs dispo :) Tu peux prendre les iso sur l'un et les hash sur l'autre ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# D'ou l'idée de diffuser le hash sur le DNS
Posté par rycks . Évalué à 10.
Oué … j'ai eu envie de faire ça pendant des années et puis je me suis dis que nos utilisateurs étaient déjà bien loin de savoir lancer md5sum (à l'époque) alors bon …
Alors pour en revenir à ta question, normalement le fichier qui contiens les empreintes est lui-même signé avec GPG et la clé GPG des développeurs diffusées sur les serveurs de clés.
eric.linuxfr@sud-ouest.org
# aucun interet ?
Posté par jigso . Évalué à 2.
Honnetement, j'ai même un doute sur l'interêt pour detecter l'erreur de lecture/transmission : je n'ai jamais vu ni entendu parler de ce type d'erreur que seul un checksum md5 aurait pu detecter.
Une erreur sur le disque et c'est une i/o error directe, lors de la communication idem, il y a des codes correcteurs d'erreurs qui au pire termine le téléchargement.
Alors oui en theorie on doit bien pouvoir trouver un scenario ou plusieurs erreurs aléatoire pourraient se compenser mutuellement, mais il faudrait surement attendre en gros l'age de l'univers pour avoir une chance de voir ça.
Mais je me trompe peut-etre, est-ce que quelqu'un à déjà eu un cas ou le md5sum a été utile (meme taille du fichier oeuf corse) ?
[^] # Re: aucun interet ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Tu oublies au moins un cas : le cas où le fichier mis à disposition n'est pas le bon. Tu le télécharges, le téléchargement se passe parfaitement bien, mais la somme de contrôle n'est pas celle annoncée. Ça arrive sur des miroirs si le fichier est visible avant d'être complètement à jour sur le miroir par exemple, tu télécharges une version tronquée (par exemple sans la fin si la copie est strictement linéaire, ou avec des problèmes par endroit si c'est une copie par morceaux). C'est un .tar.gz ou un .deb ça va se voir assez vite que le fichier est corrompu, si c'est une iso, tu ne le sauras qu'après la gravure sur DVD/le dépôt sur une clé USB, au premier démarrage dessus.
(et ton pseudo m'a fait penser à https://www.debian.org/CD/jigdo-cd/ pour rester dans le sujet)
[^] # Re: aucun interet ?
Posté par fearan . Évalué à 2.
j'ai eu des fichiers corrompus sur de long téléchargement avec reprises; eh oui, lors des temps où télécharger une iso pouvait prendre 3 jours, il n'était pas rare de devoir reprendre, d'ailleurs les brouteur web permettaient de reprendre le téléchargement
ça peut aussi arriver lors du téléchargement via p2p tu peux avoir le fichier qui a la bonne taille, mais avoir fermé prématurément le client p2p
Tu peux aussi avoir un mécanisme qui réserve le fichier de la bonne taille pour éviter la fragmentation.
Bref se baser sur la taille pour s'assurer que le fichier est complet n'est pas suffisant.
Quitte a vérifier 1 truc, autant prendre le CRC ou le md5; la taille étant souvent altéré pour une question de lisibilité, taille des secteurs… c'est absolument pas précis.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.