Como evito que o gpg inclua o SHA1?

3

apt-get está reclamando que as assinaturas são inválidas e que o arquivo InRelease não está assinado (consulte Usando o Centos para assinar pacotes .deb para o fundo). No servidor, verifiquei usando gpg que InRelease está de fato assinado.

Por Debian 9 , APT e "GPG error: ... InRelease: As seguintes assinaturas eram inválidas:" , é necessário fazer o seguinte:

Adjust the personal-digest-preferences and personal-digest-preferences in $HOME/.gnupg/gpg.conf to eliminate SHA-1 from one's GPG preferences. This prevents the problem coming back with new keys.

Após rever minha configuração do reprepro, tenho SHA1 mostrado no arquivo Release (e na assinatura do clearInsign do InRelease) e no arquivo individual do Packages, por isso espero que isso seja bem-sucedido.

~/.gnupg/gpg.conf parece indicar que usarei algoritmos de hash conforme descrito por default-preference-list e, em seguida, listará quais usar primeiro, se disponíveis.

[michael@bigbox ~]$ cat ~/.gnupg/gpg.conf
# Prioritize stronger algorithms for new keys.
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
# Use a stronger digest than the default SHA1 for certifications.
cert-digest-algo SHA512

man gpg states:

--personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg --version to get a list of available algorithms, and use none to set no preference at all. This allows the user to safely override the algorithm chosen by the recipient key preferences, as GPG will only select an algorithm that is usable by all recipients. The most highly ranked digest algorithm in this list is also used when signing without encryption (e.g. --clear-sign or --sign).

E vejo que gpg --version de fato mostra SHA1 como incluído.

michael@bigbox ~]$ gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Eu só tenho uma chave.

[michael@bigbox ~]$ gpg --list-keys
/home/michael/.gnupg/pubring.gpg
--------------------------------
pub   2048R/542342AE 2018-02-08
uid                  Michael Jones <[email protected]>
sub   2048R/4D73CC3A 2018-02-08

E experimente ...

[michael@bigbox ~]$ gpg --edit-key 542342AE
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/542342AE  created: 2018-02-08  expires: never       usage: SC
                     trust: ultimate      validity: ultimate
sub  2048R/4D73CC3A  created: 2018-02-08  expires: never       usage: E
[ultimate] (1). Michael Jones <[email protected]>

gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Set preference list to:
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)

SHA1 ainda está lá?

Observe que a postagem acima mencionada Debian 9, APT e" GPG error: ... InRelease: As seguintes assinaturas eram inválidas: " afirma que é necessário ajustar o personal-digest-preferences em $HOME/.gnupg/gpg.conf duas vezes, por isso estou preocupado com o potencial há algo mais que precisa ser alterado.

Eu não acho que isso importe, mas estou executando o Centos7.

Como evito que o gpg inclua o SHA1?

    
por user1032531 09.02.2018 / 20:12

1 resposta

0

Quando se trata de pacotes e repositórios DEB, estamos falando sobre a criação explícita de uma assinatura. Isso é diferente de criptografar e assinar uma mensagem para uma chave de destinatário conhecida. Em esse caso , o gpg usa as preferências de tecla do receptor, em combinação com suas próprias preferências locais para elaborar uma escolha de algoritmo adequada

Infelizmente, não há muitas opções disponíveis para assinatura autônoma no momento. Mesmo no GPG-2, existe apenas uma opção para desalocar um algoritmo de cifra, mas nenhuma opção para proibir um algoritmo de digitação (assinatura).

Assim, a única coisa que você pode fazer é definir explicitamente um algoritmo de digestão (assinatura) fixo em suas preferências. Porque isso é o que será usado, quando o conjunto de ferramentas debian invocar sua instalação local do GPG para fazer as assinaturas. Obviamente, isso tem o lado negativo de interferir na escolha automática de um algoritmo de assinatura; o que significa que, depois de definir essa opção, um receptor somente capaz de SHA1 não poderá mais verificar suas assinaturas.

De qualquer forma, defina o seguinte como seu ~/.gnupg/gpg.conf

digest-algo SHA256

Provavelmente você também deve colocar uma lista de preferências pessoais, o que influencia o padrão ao criar novas chaves (mas, como tal, não resolve imediatamente o problema em questão - também não vai prejudicar)

personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompre

Em relação a SHA1 e 3DES, estes são o menor denominador comum para o protocolo PGP e, portanto, conectados ao software. Eles são adicionados automaticamente no final da sua lista de preferências, para garantir a interoperação com outras implementações (fracas) do protocolo.

Veja Seção 13.2 do RfC4880

Since SHA1 is the MUST-implement hash algorithm, if it is not explicitly in the list, it is tacitly at the end.

Além disso, o SHA1 ainda é o algoritmo somente usado / permitido para gerar uma impressão digital V4 (consulte Seção 12.2 )

Bem, pode ser hora de seguir em frente, mas não há muito o que nós (usuários) podemos fazer, contanto que o padrão não seja atualizado ...

    
por 03.05.2018 / 17:49