Pour vérifier le sha1 d'un fichier, j'utiliserais openssl sha1 <file> Je ne suis pas sûr de ce qu'il faut utiliser pour vérifier le hachage sha256 du fichier, que me conseillez-vous ?
Il est également portable et fonctionne sous Ubuntu.
Réponses
Trop de publicités?
shsteimer
Points
8749
OS X est livré avec un commande shasum .
> which shasum
/usr/bin/shasumVous pouvez utiliser :
> shasum -a 256 <file>Plus de détails :
> shasum --help
Usage: shasum [OPTION]... [FILE]...
Print or check SHA checksums.
With no FILE, or when FILE is -, read standard input.
-a, --algorithm 1 (default), 224, 256, 384, 512, 512224, 512256
-b, --binary read in binary mode
-c, --check read SHA sums from the FILEs and check them
-t, --text read in text mode (default)
-p, --portable read in portable mode
produces same digest on Windows/Unix/Mac
-0, --01 read in BITS mode
ASCII '0' interpreted as 0-bit,
ASCII '1' interpreted as 1-bit,
all other characters ignored
The following two options are useful only when verifying checksums:
-s, --status don't output anything, status code shows success
-w, --warn warn about improperly formatted checksum lines
-h, --help display this help and exit
-v, --version output version information and exit
When verifying SHA-512/224 or SHA-512/256 checksums, indicate the
algorithm explicitly using the -a option, e.g.
shasum -a 512224 -c checksumfile
The sums are computed as described in FIPS-180-4. When checking, the
input should be a former output of this program. The default mode is to
print a line with checksum, a character indicating type (`*' for binary,
` ' for text, `?' for portable, `^' for BITS), and name for each FILE.
Report shasum bugs to mshelor@cpan.org
@erikvold Tu sais quoi ? Je parie que j'ai obtenu avec les outils de ligne de commande Xcode. Argh. J'aimerais vraiment qu'Apple ne pollue pas /usr/bin avec des éléments optionnels. Je vais devoir vérifier que c'est bien le cas dans la journée. Je mettrai à jour la réponse si cela provient effectivement de l'installation de XCL.
shasum renvoie un hachage différent de celui de openssl sha -sha256 <file> (ce dernier étant le hachage correct). Savez-vous pourquoi ?
leanne
Points
486
Pour clarifier La réponse utile de @John - qui vous permet de comparer un hachage donné avec son fichier en une seule commande :
Entrez shasum -a 256 -c <<< ,
suivi d'un espace facultatif,
suivi d'une simple tique ( ' ),
suivi du hachage à comparer,
suivi d'un espace,
suivi d'un caractère de mode, basé sur la façon dont le hachage initial a été généré :
-
rien si le hachage a été créé avec
-tou aucune option (mode texte, qui est le mode par défaut) -
astérisque (
*), si le hachage a été créé avec-b(mode binaire) -
point d'interrogation (
?), si le hachage a été créé avec-p(mode portable) -
caret (
^), si le hachage a été créé avec-0(mode bits)
suivi du chemin d'accès au fichier,
suivi d'une simple tique de fermeture ( ' ).
Comme la décomposition suivante, avec des parenthèses de délimitation autour des parties hash et filepath, et des crochets autour de la partie facultative "mode character". ( N'incluez pas les parenthèses ou les crochets dans la vie réelle - ils sont juste là pour rendre les parties faciles à voir ! )
shasum -a 256 -c <<< '(hashToCompare) [mode character](filepath)'Ventilation :
L'actuel shasum La commande est shasum -a 256 -c
-
-a 256dit àshasumà utiliser sha256 . -
-cdit àshasumpour "vérifier" l'entrée fournie.
El <<< est un jeu de caractères spécial d'Unix/Linux, appelé opérateur de "redirection". Il sert à introduire quelque chose dans une commande antérieure. En l'utilisant, nous disons que nous allons fournir une chaîne d'informations à la commande shasum à utiliser comme entrée.
La chaîne d'informations d'entrée doit comporter des tics simples d'ouverture et de fermeture, tels que 'some string here' ou, dans ce cas, le hachage, le caractère de mode et le chemin de fichier à vérifier.
-
El dièse à l'intérieur de la chaîne n'a pas besoin de quelque chose de spécial - mais elle doit être suivie d'un espace.
-
El caractère de mode peut être rien, un astérisque (
*), un point d'interrogation (?), ou un signe d'insertion (^). Cela signifie queshasumle mode avec lequel le hachage a été généré. (Note : aucun caractère, représentant le mode texte, n'estshasumpar défaut). -
El chemin d'accès au fichier est le chemin d'accès réel au fichier à vérifier.
Voici donc un exemple concret de vérification d'un particulier Télécharger MAMP contre son prétendu SHA-256 valeur. Le site * était nécessaire pour que ce contrôle fonctionne :
shasum -a 256 -c <<< 'f05ede012b8a5d0e7c9cf17fee0fa1eb5cd8131f3c703ed14ea347f25be11a28 *MAMP_MAMP_PRO_5.2.pkg'Note : le résultat de cette commande (pour mon fichier d'exemple) est soit -
OK :
MAMP_MAMP_PRO_5.2.pkg : OK
ou
ÉCHEC :
MAMP_MAMP_PRO_5.2.pkg : FAILED
shasum : WARNING : 1 somme de contrôle calculée ne correspond PAS
Pour moi, cela fonctionne sans l'astérisque devant le nom de fichier (ainsi qu'avec l'astérisque).
shasum -c <<< '7cb77378a0749f2a9b7e09ea62ffb13febf3759f *sample.txt' renvoie le message *sample.txt: FAILED open or read . Sans l'astérisque, sample.txt: OK . Je n'ai pas encore pu trouver le fondement de l'utilisation de l'astérisque ailleurs. Pourriez-vous préciser ?
La présence de l'astérisque indique-t-elle que la somme de contrôle utilisée comme entrée dans l'exemple a été générée en mode binaire ( avec l'option --binary ) ? Extrait de la page de manuel : "Lors de la vérification, l'entrée doit être une ancienne sortie de ce programme. Le mode par défaut est d'imprimer une ligne avec la somme de contrôle, un caractère indiquant le type ( * pour le binaire, ` ` pour le texte, U pour UNIVERSAL, ^ pour le BITS, ? pour le portable), et le nom pour chaque FICHIER". Donc, les caractères entre la somme de contrôle et le nom du fichier dépendent du mode défini lors de la création de la somme de contrôle ?
John
Points
693
