Falha de EOL em verificação de hash

Quem utiliza o sistema Linux no dia a dia e costuma verificar a integridade de arquivos através de comparações com hash, seja MD5, SHA etc. em suas respectivas ferramentas para linha de comando, provavelmente já presenciou falhas em determinadas verificações.

Os sistemas operacionais não adotam a mesma convenção para os caracteres que marcam o fim-de-linha (EOL) em arquivos de texto puro. Principalmente entre os sistemas DOS/Windows e Unix/Linux.  Como o arquivo de hash é um arquivo no formato texto, está sujeito a esta diferença em sua estrutura, caso ele tenha sido criado em um sistema ou no outro.

Ao ler um arquivo de hash, criado em um sistema Windows, ou seja, com o fim-de-linha adotado no sistema Windows, em uma ferramenta de linha de comando no Linux, haverá falha na busca do arquivo principal, o qual se pretende verificar a integridade. Algo como apresentado no exemplo a seguir:

$ sha1sum -c FreeOTFE_5_21.sha1

: Arquivo ou diretório não encontrado
: FALHOU na abertura ou na leitura
sha1sum: WARNING: 1 listed file could not be read


A solução, no sistema Linux, é converter o arquivo de hash para o formato do Unix. O comando 'dos2unix' serve para isso:

$ dos2unix FreeOTFE_5_21.sha1

dos2unix: converting file FreeOTFE_5_21.sha1 to Unix format ...


Feito isso, a verificação da integridade provavelmente não terá mais esta falha na busca do arquivo principal:

$ sha1sum -c FreeOTFE_5_21.sha1

FreeOTFE_5_21.exe: SUCESSO


Claro que o erro da integridade ainda poderá ocorrer, visto que neste caso é o arquivo principal que estará corrompido. Importante salientar que esta não é a única falha que pode ocorrer na interpretação do arquivo de hash. Algumas ferramentas de geração de hash produzem arquivos de hash com informações adicionais incluídas junto com a sequência hash, ou também em posições invertidas entre a sequência e o caminho pro arquivo principal. Tudo isso pode gerar falha na busca do arquivo. Casos assim deverão ser tratados particularmente.

Leia mais sobre EOL em http://dan-scientia.blogspot.com.br/2009/07/historia-do-fim-de-linha.html

A história do fim de linha

O ASCII (American Standard Code for Information Interchange), é uma codificação de caracteres de sete bits baseada no alfabeto inglês. Os códigos ASCII representam texto nos computadores, equipamentos de comunicação e outros dispositivos que trabalhem com texto.

A codificação define 128 caracteres, preenchendo completamente os sete bits disponíveis. Desses, 32 são caracteres de controle e não são imprimíveis, afetam somente o processamento do texto. Do restante, 94 são caracteres imprimíveis, com o espaço considerado um gráfico invisível, e há também um caractere sonoro, que apenas emite um bip ou faz piscar a tela.

Os caracteres de controle foram criados para algumas funções como o controle da impressora e da exibição na tela do monitor, estrutura de dados, controle de transmissão e outros.

Nossa história vai tratar de dois deles, o Line feed (LF) e o Carriage return (CR). O Line feed é um caractere de controle que alimenta uma nova linha no texto, ou seja, adiciona uma nova linha a partir do cursor. O Carriage return faz o retorno de carro, traz o cursor para o começo da linha. Estes caracteres são usados para marcar o fim-de-linha (EOL) em um texto.

A seqüência CR+LF era de uso comum em vários computadores que usavam máquinas teletipo como console, pois esta seqüência era necessária para posicionar a cabeça de impressão no começo de uma nova linha. O uso de dois caracteres devia-se ao fato de que os teletipos não eram rápidos o suficiente para retornar à margem esquerda em tempo hábil para apenas um caractere, assim o CR vinha em primeiro lugar. Mesmo os teletipos se tornando obsoletos, os programas criados para eles mantiveram esta seqüência de dois caracteres.

Deste modo o padrão ASCII para texto não define um único caractere para fim-de-linha. Em vez disso o padrão ASCII define dois movimentos independentes da cabeça de impressão: retorno de carro e incremento de linha.

No entanto os desenvolvedores dos sistemas operacionais modernos, por sua vez, adotaram convenções diferentes para o fim-de-linha, uns usaram LF, outros usaram CR e alguns outros usaram CR+LF:

Unix, Linux e Mac OS X: LF (Line feed, 0x0A, 10 em decimal)
Mac OS até versão 9: CR (Carriage return, 0x0D, 13 em decimal)
DOS/Windows: CR seguido de LF (CR+LF, 0x0D 0x0A)

Por exemplo, arquivos criados no Unix ou no Mac serão vistos como uma longa e única linha no Windows. Analogamente, um arquivo do Windows visto no Unix terá seus CR mostrados como um ^M ao final de cada linha ou como um segundo pula linha.

Este tipo de diferença pode ocasionar problemas quando um arquivo texto for lido em um outro sistema. Um compilador poderá falhar com erros de sintaxe obscuros, um script poderá falhar em sua execução ou um erro de leitura poderá acontecer quando um utilitário despreparado for abri-lo.

Os editores de textos mais recentes reconhecem todas as variações de fim-de-linha do tipo CR e LF, tratando adequadamente o texto, inclusive permitindo ao usuário converter entre os diferentes padrões. Infelizmente isto não vale para o editor padrão do Windows, o Bloco de notas, mas vale para o Wordpad e vale também para muitos editores do Linux.

Além dos editores de texto modernos existem os comandos dos2unix e unix2dos, no ambiente Linux, que podem ser usados para converter entre o CR+LF (DOS/Windows) e o LF (Unix).

Quem trabalha com arquivos de texto puro entre sistemas diferentes deve ficar atento quanto à estes caracteres de controle.