[Résolu] Bien comprendre le contrôle d'un fichier iso

Grognus · Le 26/02/2022, à 18:39

Bonjour,
Souhaitant migrer de Kubuntu à KDE Neon je dispose de ces fichiers :
-> neon-user-20220210-0946.iso (normalement dernière version)
-> neon-user-20220210-0946.iso.sig
-> neon-user-20220210-0946.sha256sum
Pour kubuntu, n'ayant pas vraiment compris la procédure de vérification de son iso, malgré les explications dans diverses sources, j'ai tâtonné puis j'ai fait aveuglément confiance à la source du téléchargement officiel..
Pour Neon, je souhaite faire une installation sûre évitant pour la suite, des suspicions de corruptions..
J'ai besoin de comprendre l'objet de chaque commande en plus de la seule syntaxe.
Il y a plusieurs sources de ce type de vérification, mais je cale sur les instructions dont les actions par commande m’échappent un peu.
Je souhaiterais donc recueillir vos expertises, avec mes remerciements.

Dernière modification par Grognus (Le 04/03/2022, à 23:18)

erresse · Le 26/02/2022, à 19:06

Bonjour,
Au "pifomètre", je dirais que le fichier *.iso contient la distribution à installer, le *.iso.sig serait une signature du précédent et *.sha256sum contient la somme de contrôle sha256 permettant de vérifier que le fichier iso est bien correct.
Ce serait donc l'information récupérée de ce dernier fichier que tu mettras en somme de contrôle pour vérifier l'empreinte calculée sur le fichier iso.
Note: chez moi, sous Ubuntu-Mate, le gestionnaire de fichier "Caja" propose un onglet "Empreintes" dans les "Propriétés", permettant de calculer / vérifier la somme de contrôle d'un fichier sélectionné avec toute une série de "hashages" possibles. Peut-être est-ce aussi le cas de ton gestionnaire de fichiers ?

Dernière modification par erresse (Le 26/02/2022, à 19:07)

Nuliel · Le 26/02/2022, à 19:14

Bonjour,
L'iso est un fichier lourd et sensible, il est important de vérifier son intégrité (qu'il n'a pas été modifié, que ce soit de façon malveillante ou simplement parce qu'il y a eu un pb lors du téléchargement, fait avec la somme sha256) et vérifier l'authentification (la personne qui a produit l'iso l'a signé, l'idée étant que tout le monde peut vérifier une signature mais une seule personne peut signer, cela fonctionne avec de la cryptographie asymétrique). À noter que pour la signature, cela revient à faire confiance dans celui qui a signé.
Au niveau crypto, celui qui signe génère un couple clé publique/clé privée. La clé publique est publique, donc peut (et ici doit) être diffusée sur internet. La clé privée ne doit être connue que de celui qui l'a généré. Trouver la clé privée à partir de la clé publique est impossible (hormis génération biaisée ou autres pb). On signe avec la clé privée, connue que de son propriétaire. Pour vérifier une signature, on utilise sa clé publique.

Pour l'intégrité c'est simple: sur linux tu fais

sha256sum cheminVersIso

en adaptant cheminVersIso, puis tu compares avec le contenu du retour précédent avec le contenu du fichier neon-user-20220210-0946.sha256sum (on peut aussi utiliser le paramètre -c de sha256sum pour demander au programme de faire cette comparaison)

Pour la signature, il faut utiliser gpg pour cela, mais il te manque probablement un fichier (s'il n'a pas déjà été ajouté à gpg): la clé publique de celui qui a fait la signature. Sur https://neon.kde.org/download, il est indiqué la clé publique: https://keyserver.ubuntu.com/pks/lookup … 00075E1D76
Il faut que tu la télécharges, et que tu l'importes:

gpg --import pubkey.gpg

(en supposant que tu aies appelé le fichier précédemment téléchargé pubkey.gpg), puis

gpg --verify neon-user-20220210-0946.iso.sig neon-user-20220210-0946.iso

permet de vérifier.

Edit: dans le cas d'ubuntu, cette ressource est très bien: https://ubuntu.com/tutorials/how-to-ver … 1-overview

Dernière modification par Nuliel (Le 26/02/2022, à 19:16)

abecidofugy · Le 26/02/2022, à 20:40

@Grognus : il me semble que si tu récupères l’ISO par P2P (torrent) tu n’as pas besoin de vérifier l’intégrité du fichier ainsi récupéré. il faut le faire bien sûr par la page officielle de la distro.

//EDIT : concernant la fraîcheur de l’ISO, il ne faut pas forcément toujours avec la toute dernière : une fois installé, la distro se mettra à jour
KDE neon fait des iSO très très régulièrement.

Dernière modification par abecidofugy (Le 26/02/2022, à 20:43)

Grognus · Le 27/02/2022, à 23:38

Vos réponses m’ont éclairé et je vous en remercie beaucoup.
Ainsi j’utiliserais P2P (torrent) indiqué par Abecidofugy pour télécharger un prochain iso ou si l’actuel se révèle douteux.
Mon il a déjà demandé 8 heures de récupération au terme de 2 téléchargements car il y a eu un échec à quelques dizaines de secondes de la fin pour le premier. Il y a eu d’ailleurs le même incident pour le second, mais j’ai préféré tenter son relancement, jusqu’à ce que soit enfin indiqué « Terminé », d’où un doute et mon intérêt à vérifier son intégrité.
Pour cela, j’ai exploité les opérations indiquées par Nuliel.
La première commande :

sha256sum cheminVersIso

a révélé un souci d’interprétation des espaces dans le déroulé du chemin. L’iso a été enregistrée sur un disque dur extérieur et le chemin est long avec des espaces.
Mais je me suis souvenu d’une possibilité pour palier le problème, en ouvrant directement le terminal dans le dossier de l’iso, où qu’il soit :
--> clic droit dans le dossier en question → Actions → Ouvrir un terminal ici
J’ai obtenu je pense, la clé publique mais je n’ai pas bien compris l’usage du paramètre de comparaison « -c » car en le plaçant après la syntaxe principale, cela semble bloquer mon terminal.
Au départ, il me manquait bien un fichier .gpg ajouté avec le lien de Nuliel:
https://keyserver.ubuntu.com/pks/lookup … 00075E1D76
que j’ai enregistré par un clic droit sur ce lien en sélectionnant : « Enregistrer la cible du lien sous » avec l'intitulé : « clepublique.gpg », toujours dans le dossier de l’iso.
Ensuite j’ai importé la clé publique du dernier fichier enregistré :

gpg --import clepublique.gpg

pour reprendre le nom que j'ai donné à ce fichier.
et enfin, la vérification avec le fichier « .sig » :

gpg --verify neon-user-20220210-0946.iso.sig neon-user-20220210-0946.iso

qui retourne :

gpg: Signature faite le jeu. 10 févr. 2022 11:01:06 CET
gpg:                avec la clef RSA 348C8651206633FD983A8FC4DEACEA00075E1D76
gpg: Bonne signature de « KDE neon ISO Signing Key <neon@kde.org> » [inconnu]
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg:          Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 348C 8651 2066 33FD 983A  8FC4 DEAC EA00 075E 1D76

À part l’indication : « gpg: Bonne signature de « KDE neon ISO Signing Key »...» je vois qu’il reste quelques incertitudes du type : « Attention : cette clef n'est pas certifiée avec une signature de confiance ».

Dernière modification par Grognus (Le 27/02/2022, à 23:46)

MicP · Le 28/02/2022, à 01:28

Bonjour

Dans son message #1, Grognus a écrit :

…comprendre l'objet de chaque commande …

Va lire les pages web suivantes :
https://en.wikipedia.org/wiki/Secure_Hash_Algorithms

https://fr.wikipedia.org/wiki/Pretty_Go … tionnement

…et les pages man des commandes concernées
en lançant les lignes de commande suivantes :

man sha256sum

et

man gpg

Après avoir lu ces pages man et web, ça te sera beaucoup plus facile de citer les passages que tu as du mal à comprendre pour préciser ta demande d'aide
sinon ça ne va pas être du tout évident d'arriver à expliquer tout ça avec seulement quelques messages dans un fil de discussion
sans vraiment bien savoir ce qui te bloque.

===
Du coup, ce fil de discussion devra peut-être être scindé en deux fils :
- un concernant sha
- et un autre concernant gpg

=======
Quelques (très brèves) définitions :

- Authentification : assurer que seules les personnes autorisées aient accès aux ressources.
- Non répudiation : garantir qu'une transaction ne peut être niée.
- Intégrité : garantir que les données sont bien celles que l'on croit être.
- Confidentialité : rendre l'information inintelligible à d'autres personnes que les seuls acteurs d’une transaction.

Dernière modification par MicP (Le 28/02/2022, à 02:21)

Grognus · Le 28/02/2022, à 10:44

Bonjour MicP,
Merci pour tes indications très précises.
Quand je désirais bien comprendre les commandes permettant de vérifier la conformité de mon iso, je ne pensais pas découvrir, et j'en suis désolé, que mon niveau d'utilisateur était à ce point décalé.
Bien sûr, tout s'apprend, mais il faudrait que je n'y sois pour personne durant mes 20 prochaines années en commençant par des cours accélérés d'anglais technique et des pilules de jouvence.
Afin d'utiliser KDE Neon dans un meilleur délai, puis-je considérer que je n'obtiendrais pas de meilleurs résultats d'authentification que ceux que j'ai produits en #5 et qu'ils me donnent le feu vert pour une installation sûre ?

cqfd93 · Le 28/02/2022, à 11:19

Bonjour,

abecidofugy a écrit :

@Grognus : il me semble que si tu récupères l’ISO par P2P (torrent) tu n’as pas besoin de vérifier l’intégrité du fichier ainsi récupéré. il faut le faire bien sûr par la page officielle de la distro.

Autre avantage non négligeable : le téléchargement peut être interrompu et repris à tout moment, on ne repart jamais à zéro.

Grognus · Le 28/02/2022, à 12:14

Effectivement cqfd93, c'est un avantage pour les téléchargments longs et l'assurance d'avoir un iso conforme dans ce que tu dis. J'aurais dû passer par ce téléchargment. Pour autant, mon iso actuel, compte tenu des vérifications obtenues, s'il est bon à l'usage, j'effectuerais pour un prochain besoin, un téléchargemnt « Torrent ».
Mais pourquoi existe-t-il l'autre type d'acquisition de l'iso mis en avant, s'il est moins sûr ?
En tout cas merci pour ton intervention.

abecidofugy · Le 28/02/2022, à 14:36

Grognus a écrit :

Effectivement cqfd93, c'est un avantage pour les téléchargments longs et l'assurance d'avoir un iso conforme dans ce que tu dis. J'aurais dû passer par ce téléchargment. Pour autant, mon iso actuel, compte tenu des vérifications obtenues, s'il est bon à l'usage, j'effectuerais pour un prochain besoin, un téléchargemnt « Torrent ».
Mais pourquoi existe-t-il l'autre type d'acquisition de l'iso mis en avant, s'il est moins sûr ?
En tout cas merci pour ton intervention.

Tout le monde n’a pas un OS fonctionnel, avec Torrent installé dessus (ou sachant ce que c’est). Donc ils offrent aussi la voie du téléchargement serveur.

Nuliel · Le 28/02/2022, à 23:01

À noter qu'on peut reprendre un téléchargement interrompu avec wget -c (je l'utilise jamais mais c'est tjs bon à savoir).

À part l’indication : « gpg: Bonne signature de « KDE neon ISO Signing Key »...» je vois qu’il reste quelques incertitudes du type : « Attention : cette clef n'est pas certifiée avec une signature de confiance ».

En fait tu as vérifié que l'iso a été signée par le propriétaire de la clé que tu as téléchargé. On pourrait aller encore plus loin en faisant en sorte que la clé soit signée par une autorité de certification dans lequel tu as confiance (en gros on peut faire du chaînage). Voilà le pourquoi de l'avertissement.
Sinon c'est des pb de cryptographie en fait

Grognus · Le 03/03/2022, à 16:23

Si la signature de l'iso peut être considérée comme bonne, j'ai négligé son intégrité.
La méthode suivante au terminal me laisse encore des incertitudes.
Après avoir ouvert un terminal dans le dossier de l'iso par clic droit et "Actions" j'ai d'abord tapé la commande :

sha256sum neon-user-20220210-0946.iso -c neon-user-20220210-0946.sha256sum

qui donne le retour :

sha256sum: neon-user-20220210-0946.iso : n'a trouvé aucune ligne de somme de contrôle correctement formatée selon SHA256
neon-user-20220210-0946.iso: Réussi

En effectuant la commande ne mentionnant pas le nom du fichier iso dans le dossier :

sha256sum -c neon-user-20220210-0946.sha256sum

le terminal n'indique plus un défaut de "formatage" :

neon-user-20220210-0946.iso: Réussi

Mais cette indication "Réussi", traduit-elle bien l'intégrité de l'iso compte tenu que le nom de son fichier n'est pas fourni dans la seconde syntaxe ?

erresse · Le 03/03/2022, à 17:36

Mais cette indication "Réussi", traduit-elle bien l'intégrité de l'iso compte tenu que le nom de son fichier n'est pas fourni dans la seconde syntaxe ?

Je pense que le "réussi" indique que le programme a bien calculé la clé pour l'iso, mais il ne l'a pas vérifiée car le fichier "neon-user-20220210-0946.sha256sum" de contrôle ne semble pas contenir la clé de contrôle...

Grognus · Le 03/03/2022, à 18:58

Ok erresse, il y aurait un problème...
Le Téléchargement ayant eu lieu sur le site de KDE Neon :
https://neon.kde.org/download
je peux raisonnablement faire confiance à la légalité de l'iso mais pas totalement à son intégrité lié au bon déroulement technique de son transfert. En revanche, le poids du fichier à l'arrivée est conforme.

erresse · Le 03/03/2022, à 19:05

Dans mon premier message (#2), je te suggérais ceci :

erresse a écrit :

Note: chez moi, sous Ubuntu-Mate, le gestionnaire de fichier "Caja" propose un onglet "Empreintes" dans les "Propriétés", permettant de calculer / vérifier la somme de contrôle d'un fichier sélectionné avec toute une série de "hashages" possibles. Peut-être est-ce aussi le cas de ton gestionnaire de fichiers ?

En passant par cette procédure, tu peux indiquer la clé de contrôle dans le fenêtre de vérification et ainsi avoir la confirmation que le fichier téléchargé est bien intègre.
Normalement, cette clé de contrôle est à copier directement sur le site où l'on télécharge l'iso, ou peut-être dans le fichier "neon-user-20220210-0946.sha256sum" qui doit juste être un fichier texte d'une seule ligne.

MicP · Le 03/03/2022, à 21:58

Bonjour

On peut télécharger les deux fichiers
- neon-user-20220210-0946.iso
- neon-user-20220210-0946.sha256sum
en lançant la ligne de commande sivante :

wget https://files.kde.org/neon/images/user/current/neon-user-20220210-0946.{sha256sum,iso}

une fois ces 2 fichiers téléchargés,
ça va donner :

michel@debbull:~/atester$ ls -l neon-user-20220210-0946.{sha256sum,iso}
total 1937416
-rw-r--r-- 1 michel michel 1983905792 10 févr. 11:01 neon-user-20220210-0946.iso
-rw-r--r-- 1 michel michel         94 10 févr. 11:01 neon-user-20220210-0946.sha256sum
michel@debbull:~/atester$

on peut faire s'afficher le contenu du fichier neon-user-20220210-0946.sha256sum

michel@debbull:~/atester$ cat neon-user-20220210-0946.sha256sum
f139b2501219b8688b5864ee4204cb3b72685d9911f88f2b8067414b00a720f9  neon-user-20220210-0946.iso
michel@debbull:~/atester$

et on peut demander la somme de contrôle sha256
du fichier neon-user-20220210-0946.iso

michel@debbull:~/atester$ sha256sum neon-user-20220210-0946.iso
f139b2501219b8688b5864ee4204cb3b72685d9911f88f2b8067414b00a720f9  neon-user-20220210-0946.iso
michel@debbull:~/atester$

ou bien :

michel@debbull:~/atester$ sha256sum -c neon-user-20220210-0946.sha256sum
neon-user-20220210-0946.iso: Réussi
michel@debbull:~/atester$

Ce qui veux dire : la somme de contrôle sha256 du fichier neon-user-20220210-0946.iso téléchargé
correspond à celle du fichier source du téléchargement.

========
MAIS, je vais "corrompre" les données contenues dans le fichier iso :

michel@debbull:~/atester$ dd if=/dev/zero of=neon-user-20220210-0946.iso skip=1 count=1
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets copiés, 0,000615038 s, 832 kB/s
michel@debbull:~/atester$

et maintenant, le contrôle ne renvoie plus du tout le même message :

michel@debbull:~/atester$ sha256sum -c neon-user-20220210-0946.sha256sum
neon-user-20220210-0946.iso: Échec
sha256sum: Attention : 1 somme de contrôle ne correspond pas
michel@debbull:~/atester$

effectivement, le contenu du fichier ayant été modifié
la somme de contrôle du fichier n'est plus la même :

michel@debbull:~/atester$ sha256sum neon-user-20220210-0946.iso
076a27c79e5ace2a3d47f9dd2e83e4ff6ea8872b3c2218f66c92b89b55f36560  neon-user-20220210-0946.iso
michel@debbull:~/atester$

Grognus · Le 04/03/2022, à 12:01

Merci MicP, je dispose déjà des fichiers :
- neon-user-20220210-0946.iso
- neon-user-20220210-0946.sha256sum
Ma commande de mon post #12 :

sha256sum -c neon-user-20220210-0946.sha256sum

qui retourne "Réussi" atteste donc l'intégrité de mon iso.

MicP · Le 04/03/2022, à 15:45

Bonjour

Grognus a écrit :

…Ma commande de mon post #12 :
sha256sum -c neon-user-20220210-0946.sha256sum
qui retourne "Réussi" atteste donc l'intégrité de mon iso.

Oui

Grognus · Le 04/03/2022, à 23:14

Merci à tous, mon sujet est résolu.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/02/2022, à 18:39

[Résolu] Bien comprendre le contrôle d'un fichier iso

#2 Le 26/02/2022, à 19:06

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#3 Le 26/02/2022, à 19:14

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#4 Le 26/02/2022, à 20:40

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#5 Le 27/02/2022, à 23:38

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#6 Le 28/02/2022, à 01:28

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#7 Le 28/02/2022, à 10:44

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#8 Le 28/02/2022, à 11:19

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#9 Le 28/02/2022, à 12:14

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#10 Le 28/02/2022, à 14:36

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#11 Le 28/02/2022, à 23:01

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#12 Le 03/03/2022, à 16:23

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#13 Le 03/03/2022, à 17:36

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#14 Le 03/03/2022, à 18:58

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#15 Le 03/03/2022, à 19:05

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#16 Le 03/03/2022, à 21:58

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#17 Le 04/03/2022, à 12:01

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#18 Le 04/03/2022, à 15:45

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

#19 Le 04/03/2022, à 23:14

Re : [Résolu] Bien comprendre le contrôle d'un fichier iso

Pied de page des forums