Para comprobar el sha1 de un archivo utilizaría openssl sha1 <file> Sin embargo, no estoy seguro de qué utilizar para comprobar el hash sha256 del archivo, ¿qué me recomiendas?
Esto también es portátil y se ejecuta en ubuntu.
Respuestas
¿Demasiados anuncios?
shsteimer
Puntos
8749
OS X viene con un comando shasum .
> which shasum
/usr/bin/shasumPuedes usar:
> shasum -a 256 <file>Más detalles:
> 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 ¿Sabes qué? Seguro que tengo con las herramientas de línea de comandos de Xcode. Argh. Realmente me gustaría que Apple no contaminara /usr/bin con cosas opcionales. Tendré que verificar que esto es así hoy mismo. Actualizaré la respuesta si efectivamente proviene de la instalación de XCL.
shasum devuelve un hash diferente al de openssl sha -sha256 <file> (siendo este último el hash correcto). ¿Alguna idea de por qué?
Nickparsa
Puntos
140
Para aclarar La útil respuesta de @John - que permite comparar un hash dado con su archivo en un solo comando:
Entre en shasum -a 256 -c <<< ,
seguido de un espacio opcional,
seguido de una sola marca ( ' ),
seguido del hash a comparar,
seguido de un espacio,
seguido de un carácter de modo, basado en cómo se generó el hash inicial:
-
nada si el hash fue creado con
-to ninguna opción (modo texto, que es el predeterminado) -
asterisco (
*), si el hash fue creado con-b(modo binario) -
signo de interrogación (
?), si el hash fue creado con-p(modo portátil) -
caret (
^), si el hash fue creado con-0(modo bits)
seguido de la ruta del archivo,
seguido de un tic de cierre ( ' ).
Como el siguiente desglose, con paréntesis de delimitación alrededor de las partes hash y filepath, y corchetes alrededor de la parte opcional "carácter de modo". ( No incluyas los paréntesis ni los corchetes en la vida real: ¡sólo están aquí para que las partes sean fáciles de ver! )
shasum -a 256 -c <<< '(hashToCompare) [mode character](filepath)'Descompuesto :
El actual shasum comando es shasum -a 256 -c
-
-a 256diceshasumpara usar sha256 . -
-cdiceshasumpara "comprobar" la entrada proporcionada.
El <<< es un conjunto de caracteres especiales de Unix/Linux, llamado operador de "redirección". Sirve para introducir algo en un comando anterior. Al usarlo, estamos diciendo que vamos a proporcionar una cadena de información para el shasum para usar como entrada.
La cadena de información de entrada debe tener marcas simples de apertura y cierre, como 'some string here' o, en este caso, el hash, el carácter de modo y la ruta del archivo a comprobar.
-
El hash dentro de la cadena no necesita nada especial, pero debe ir seguida de un espacio.
-
El carácter de modo puede ser nada, un asterisco (
*), un signo de interrogación (?), o un signo de interrogación (^). Esto indicashasumel modo con el que se generó el hash. (Nota: ningún carácter, que represente el modo texto, esshasumpor defecto). -
El ruta del archivo es la ruta real del archivo que se va a comprobar.
He aquí un ejemplo de la vida real en el que se comprueba un Descarga de MAMP archivo contra su supuesta SHA-256 valor. El * para que esta comprobación funcione:
shasum -a 256 -c <<< 'f05ede012b8a5d0e7c9cf17fee0fa1eb5cd8131f3c703ed14ea347f25be11a28 *MAMP_MAMP_PRO_5.2.pkg'Nota: el resultado de este comando (para mi archivo de ejemplo) es
BIEN:
MAMP_MAMP_PRO_5.2.pkg: OK
o
FALLÓ:
MAMP_MAMP_PRO_5.2.pkg: FAILED
shasum: ADVERTENCIA: 1 suma de comprobación calculada NO coincide
Para mí esto funciona sin el asterisco antes del nombre del archivo (así como con el asterisco).
shasum -c <<< '7cb77378a0749f2a9b7e09ea62ffb13febf3759f *sample.txt' devuelve el mensaje *sample.txt: FAILED open or read . Sin el asterisco, sample.txt: OK . Todavía no he podido encontrar el fundamento del uso del asterisco en otro lugar. ¿Podría aclararlo?
¿La presencia del asterisco indica que la suma de comprobación utilizada como entrada en el ejemplo fue generada en modo binario ( con --binary )? De la página man: "Cuando se comprueba, la entrada debe ser una salida anterior de este programa. El modo por defecto es imprimir una línea con la suma de comprobación, un carácter que indica el tipo ( * para el binario, ` ` para el texto, U para UNIVERSAL, ^ para BITS, ? para el portátil), y el nombre de cada ARCHIVO". Entonces, ¿los caracteres entre la suma de comprobación y el nombre del archivo dependen del modo establecido cuando se creó la suma de comprobación?
John
Puntos
16
