Como verificar downloads com checksum no Linux

Verifique um download com um checksum em dois minutos

Para verificar um download com um checksum, calcule o hash do ficheiro recebido e deixe uma ferramenta comparar esse hash com o hash publicado pelo fornecedor. O sha256sum faz as duas partes do trabalho: por si só, mostra um digest e, com -c, lê uma lista de digests e indica quais ficheiros correspondem. Este guia executa todo o processo num ficheiro que cria e, em seguida, altera esse ficheiro de propósito para que veja a falha acontecer, em vez de apenas ler sobre ela.

Tenha sempre presente uma frase. Um checksum indica se os bytes que possui são os bytes que produziram o digest, mas não indica quem os produziu. Essa segunda questão requer uma assinatura e uma chave em que confie. A última parte deste guia mostra exatamente onde fica a distinção entre as duas coisas.

Crie um ficheiro para praticar

Trabalhe num diretório temporário para que nada do que fizer aqui afete o resto do sistema. Todos os comandos abaixo fazem parte do GNU coreutils, o conjunto de comandos base presente em qualquer servidor Ubuntu ou Debian. Não é necessário instalar nada.

mkdir -p ~/checksum-demo
cd ~/checksum-demo
printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum payload.txt

É apresentada uma linha: 64 caracteres hexadecimais, dois espaços e o nome do ficheiro. Esses 64 caracteres são o digest do ficheiro. Execute o comando novamente e a linha será idêntica, porque o hashing é determinístico: a mesma entrada produz sempre a mesma saída. Altere um caractere do ficheiro e execute o comando novamente. O digest não muda ligeiramente. Fica completamente diferente, porque inverter um bit da entrada inverte cerca de metade dos bits da saída. Essa propriedade permite usar uma string de 64 caracteres como representação de uma imagem de 4 GB.

Guardar um ficheiro SHA256SUMS e verificá-lo

Um digest apresentado no ecrã não é útil no dia seguinte. Grave-o num ficheiro, no formato que o próprio sha256sum escreve, para que a ferramenta o possa ler mais tarde.

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

sha256sum -c lê cada linha da lista, calcula o hash do ficheiro indicado nessa linha e compara os dois digests. Uma execução sem problemas apresenta uma linha por ficheiro:

payload.txt: OK

Verifique também o estado de saída, porque um script lê esse valor e nunca lê o texto. echo $? apresenta 0 depois de uma execução bem-sucedida. O nome SHA256SUMS é uma convenção, não uma regra, mas as distribuições e a maioria das páginas de versões usam-no. Use-o também para que a pessoa seguinte saiba o que o ficheiro contém sem o abrir.

Alterar um byte e observar a falha da verificação

Agora danifique o ficheiro de propósito. Este comando escreve um único byte no offset 5 e deixa todo o resto inalterado, por isso o ficheiro mantém o tamanho e o nome.

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

conv=notrunc é a flag relevante: sem ela, dd trunca o ficheiro no ponto onde deixa de escrever, e estaria a testar um tipo de dano muito mais evidente. A verificação apresenta agora:

payload.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

echo $? apresenta 1. FAILED significa que o ficheiro foi lido e que o seu digest não corresponde ao valor existente na lista. Reponha os bytes originais e confirme que a verificação volta a apresentar OK:

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

Esse é todo o procedimento. Uma diferença de um byte, em qualquer ponto do ficheiro, produz FAILED. Uma transferência interrompida por uma ligação perdida, um mirror que disponibiliza a build do dia anterior, um proxy que reescreveu o ficheiro durante o trânsito ou um disco que devolveu um bloco inválido: todos esses casos aparecem na mesma linha.

Quando a lista menciona um ficheiro que não descarregou

Um ficheiro SHA256SUMS real de uma distribuição lista todas as imagens que o projeto disponibiliza, e você descarregou apenas uma delas. Reproduza essa situação aqui.

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 é uma falha diferente de FAILED, e confundir as duas faz perder tempo. FAILED significa que os bytes estão incorretos. FAILED open or read significa que sha256sum nem sequer encontrou o ficheiro, portanto nada foi comparado. Num download real, a causa habitual é o diretório de trabalho, porque os nomes da lista são relativos ao diretório onde executa o comando. Mude para o diretório que contém o ficheiro e execute-o novamente. Para verificar apenas o que tem efetivamente, peça isso:

sha256sum --ignore-missing -c SHA256SUMS.all

Isto imprime payload.txt: OK e termina com o código 0. Se nenhum dos nomes listados estiver presente, --ignore-missing não termina silenciosamente com zero ficheiros. Indica no file was verified e termina com um código diferente de zero. Esse é o comportamento pretendido, porque uma validação que não verificou nada seria uma falha que nunca detetaria.

Cole um digest publicado sem o ler visualmente

Comparar 64 caracteres hexadecimais visualmente é o ponto em que este hábito falha. As pessoas verificam os primeiros quatro caracteres e os últimos quatro e consideram que há correspondência. É exatamente essa comparação que um atacante determinado procura explorar. Deixe a ferramenta fazer a comparação. Defina EXPECTED com o digest copiado do publicador, usando EXPECTED= seguido do valor colado. Depois, construa a única linha que -c espera:

printf '%s  %s\n' "$EXPECTED" payload.txt > payload.sha256
cat payload.sha256
sha256sum -c payload.sha256

Há dois espaços entre o digest e o nome do ficheiro. Por isso, a string de formato contém dois espaços. Este é o formato que sha256sum escreve e que -c analisa. Um ficheiro que contenha apenas um digest não é uma linha de checksum. Por isso, a verificação rejeita o ficheiro inteiro com no properly formatted checksum lines found, em vez de tentar adivinhar a que ficheiro se refere. Alguns projetos publicam o formato com etiqueta BSD, usando SHA256 (payload.txt) = seguido do digest. O GNU coreutils escreve esse formato com sha256sum --tag payload.txt e lê-o novamente com -c. Pode guardar qualquer um dos dois formatos.

Quando uma verificação apresenta um comportamento estranho, veja a própria lista com cat -A SHA256SUMS. Esse comando marca o fim de cada linha com $ e mostra caracteres que, de outra forma, não conseguiria ver. Uma linha terminada em ^M$ recebeu um carriage return de um editor do Windows. O GNU sha256sum ignora esse caractere final e continua a apresentar OK. Portanto, uma lista CRLF não é a causa da falha da verificação, embora as ferramentas fora do coreutils sejam menos tolerantes. Normalize a cópia que guardar com tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

O que comprova uma checksum e o que não comprova?

Uma checksum comprova uma coisa: os bytes no seu disco são os bytes que produziram o digest publicado. Isto deteta completamente danos acidentais. Também deteta um atacante descuidado que substituiu o ficheiro num mirror de download, mas não conseguiu alterar a página que publicou o digest.

Não comprova a autoria. Um digest é um facto sobre bytes, não sobre pessoas. Se uma página fornece tanto o ficheiro como o digest, quem conseguir alterar um também consegue alterar o outro, e a sua linha OK significa apenas que o mirror concorda consigo próprio. Por isso, esta é a regra que torna útil verificar checksums: obtenha o digest de um local diferente daquele de onde obteve o ficheiro. Por exemplo, obtenha-o no domínio do próprio projeto através de TLS (transport layer security), enquanto a imagem veio de um mirror ou de um torrent. Assim, um atacante tem de controlar dois locais em vez de um. Isto também não diz nada sobre o que esses bytes verificados farão depois de os executar. Essa é uma questão separada que vale a pena colocar sobre qualquer coisa que seja executada em seu nome, desde um script de instalação até um plugin dsh executado com as permissões do seu agente.

O algoritmo também é importante. O SHA-256 (secure hash algorithm, saída de 256 bits) não tem nenhuma colisão conhecida em agosto de 2026, razão pela qual os publicadores o utilizam. O MD5 (message digest 5) e o SHA-1 não são adequados: desde 2004 é possível construir dois ficheiros diferentes com o mesmo digest MD5, e uma colisão SHA-1 com prefixo escolhido foi publicada em 2020. Um ficheiro MD5SUMS continua a detetar um download truncado, porque a corrupção aleatória não é uma colisão criada deliberadamente. Não impede alguém que esteja a tentar enganá-lo. Quando um projeto publica ambos, utilize a linha SHA-256.

Quando as assinaturas assumem o controlo

Uma assinatura elimina a lacuna deixada por um digest. O editor assina o ficheiro de digests com uma chave privada, e você verifica-o com a chave pública correspondente: gpg --verify SHA256SUMS.asc SHA256SUMS. Se essa verificação passar, a lista de digests veio de quem possui essa chave. Depois, sha256sum -c SHA256SUMS associa o ficheiro no seu disco à lista, e a cadeia de confiança estende-se da chave até aos bytes.

O ponto fraco passa a ser a chave. Obter a chave na mesma página que forneceu o ficheiro entrega novamente as duas partes ao atacante. O GnuPG deixa isso claro, e a primeira verificação apresenta Good signature juntamente com WARNING: This key is not certified with a trusted signature!. Good signature significa que a validação matemática está correta. Não significa que a chave pertença ao projeto que você tem em mente. Obtenha a impressão digital a partir de uma segunda fonte, como a documentação do projeto noutro domínio ou um pacote de distribuição que já inclua a chave, e compare a impressão digital completa em vez dos últimos oito caracteres. Esta é a mesma atenção que uma chave privada SSH exige, pelo mesmo motivo: a chave é a decisão de confiança, e tudo o que vem depois herda essa confiança.

As compilações reproduzíveis levam esta ideia um passo mais longe. Um digest publicado ainda o associa a um binário criado por uma única máquina. Quando a compilação de um projeto é reproduzível, qualquer pessoa pode compilar o mesmo código-fonte e obter uma saída idêntica byte a byte. Assim, compiladores independentes podem confirmar o digest publicado, em vez de lhe pedirem para confiar na palavra de um único servidor. Isto torna-se mais importante a cada ano, à medida que mais código chega através de pipelines automatizados e patches escritos por máquinas. Decidir o que é aceite numa compilação é uma questão de política, e as políticas de código aberto para código assistido por IA atuam sobre a mesma cadeia de fornecimento a partir da outra extremidade.

O seu gestor de pacotes já faz isto por si

No Debian e no Ubuntu, apt executa esta cadeia em cada instalação, sem pedir confirmação. O índice de pacotes contém um resumo SHA-256 para cada ficheiro .deb. O ficheiro Release contém os resumos desses ficheiros de índice, e InRelease contém uma assinatura sobre Release, verificada com base nas chaves em /usr/share/keyrings e /etc/apt/trusted.gpg.d. Quando a cadeia falha, o apt informa-o: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY quando falta a chave de um repositório de terceiros, ou Hash Sum mismatch quando o índice obtido não corresponde ao Release assinado, o que normalmente significa que um proxy de cache forneceu um ficheiro desatualizado ou que o mirror estava a ser sincronizado.

Esse é o padrão de comparação quando a página inicial de um projeto pede para encaminhar um script de curl diretamente para uma shell. Nenhum mecanismo verifica os bytes e você nunca os vê. O servidor também pode devolver uma coisa a um script e outra a um browser, e você não fica com uma cópia para analisar depois. Transfira o ficheiro com curl -fsSL <url> -o install.sh, calcule o hash, leia-o com less e só depois execute-o. Este procedimento demora cerca de vinte segundos e é o mesmo que vale a pena começar a aplicar num VPS novo, nos primeiros dez minutos, antes de instalar qualquer outra coisa no servidor.

Mantenha uma lista de digests do que instalar manualmente

Os pacotes instalados por apt são monitorizados. Um binário que copiou para /usr/local/bin não é, e nada no sistema o monitoriza. Uma lista de digests transforma isso em algo que pode verificar quando quiser:

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

--quiet não imprime nada quando todos os ficheiros correspondem e imprime apenas as linhas que falharam quando alguns não correspondem. Portanto, o silêncio indica sucesso e echo $? confirma-o com 0. Este é o formato a usar numa tarefa agendada. --status vai mais longe e não imprime absolutamente nada, deixando apenas o código de saída. Aponte o mesmo padrão para ficheiros reais com sha256sum /usr/local/bin/* > ~/local-bin.sha256 para criar uma referência. Os caminhos são guardados na lista exatamente como foram introduzidos. Por isso, os caminhos absolutos fazem a verificação funcionar a partir de qualquer diretório.

Tenha claro o valor dessa referência. Ela deteta um ficheiro alterado. Não deteta um atacante que já tenha acesso a root, porque esse atacante pode reescrever inventory.sha256 com a mesma facilidade com que reescreveu o binário. Mantenha a lista fora da máquina se quiser que ela tenha algum valor. Isto faz parte da questão mais ampla de quanto do VPS está realmente a confiar e de quem mais pode aceder ao disco subjacente.

FAQ

Uma soma de verificação correspondente significa que o download é seguro?

Não. Isso significa que os bytes que tem correspondem ao resumo criptográfico com o qual os comparou. Se o atacante controlar a página que publicou o resumo, pode publicar o resumo do próprio ficheiro, e a verificação apresenta OK. Uma correspondência confirma apenas a consistência. Para confirmar a segurança, é necessária uma assinatura verificada com uma chave obtida de outra fonte. Só depois o resumo criptográfico herda essa confiança.

Porque é que sha256sum -c apresenta FAILED open or read?

Porque não leu o ficheiro. Uma linha separada, imediatamente acima, indica No such file or directory com o nome procurado. Os nomes num ficheiro SHA256SUMS são relativos ao diretório onde executa o comando. Por isso, mude para o diretório que contém o download e execute-o novamente. Se a lista também incluir ficheiros que não descarregou, adicione --ignore-missing. Um FAILED simples, sem open or read, indica a situação oposta: o ficheiro foi lido, mas o resumo criptográfico não correspondeu.

O MD5 é suficiente para verificar um download?

Para detetar danos acidentais, sim. Uma transferência truncada ou um bloco defeituoso do disco não produzirá por acaso um resumo MD5 correspondente. Contra um atacante, não. É possível construir dois ficheiros diferentes com o mesmo resumo MD5 desde 2004, e o SHA-1 sofreu uma colisão de prefixo escolhido em 2020. Use a linha SHA-256 quando um projeto publicar ambas, e interprete um projeto que use apenas MD5 como sinal de um processo de lançamento antigo.

Qual é a diferença entre sha256sum -c e gpg --verify?

sha256sum -c prova que um ficheiro corresponde a um resumo criptográfico. gpg --verify prova que um ficheiro de resumos criptográficos foi assinado pelo titular de uma determinada chave privada. Respondem a perguntas diferentes. Por isso, execute ambos quando o projeto disponibilizar ambos. A assinatura torna a lista de resumos confiável, e a lista de resumos torna o ficheiro descarregado confiável.

Como verifico um ficheiro contra um resumo criptográfico apresentado numa página Web?

Não compare os caracteres visualmente. Guarde o resumo e o nome do ficheiro numa única linha, separados por dois espaços. Depois, execute sha256sum -c contra esse ficheiro e leia o OK ou FAILED apresentado. Criar a linha com printf '%s %s\n' evita erros de formatação que fazem sha256sum rejeitar o ficheiro com no properly formatted checksum lines found.