Questão gpg2: nenhuma chave secreta


Eu uso o enigmail há mais de um ano sem problemas e hoje ele não funciona.

Eu encontrei o seguinte fato interessante:

gpg --decrypt something.gpg # this works
gpg2 --decrypt something.gpg # this fails

Então, algo está quebrado com o gpg versão 2 na minha máquina.

Isso me levou a ver que:

gpg --list-secret-keys # reads from ~/.gnupg/secring.gpg
gpg2 --list-secret-keys # reads from ~/.gnupg/pubring.gpg (pubring?!) 

Esta parece ser a raiz do problema ... claro gpg2 não consegue encontrar a chave secreta porque está procurando no arquivo errado.

Como poderia meu gpg2 falhar quando meu gpg funciona bem? Eu não vejo nenhuma opção para especificar de onde as chaves secretas são lidas.

Alguém tem alguma ideia?


Resposta ao @grawity:

Obrigado, agradeço sua ajuda. Irã stracee vejo o que você está falando.

No entanto, mesmo depois gpg2 --import ... Não vejo diferença no comportamento. Eu só posso fazê-lo funcionar se eu reiniciar (sem iniciar o gpg-agent), executar gpg2 --import ..., então corra gpg2 --decrypt .... Depois dessa sequência, o thunderbird + enigmail também se comporta bem. No entanto, depois de 15 minutos ou mais (meu palpite é que a senha que eu digitei para descriptografar expirou), então gpg-agent está de volta ao seu antigo comportamento. Essa sequência é repetida.

Então, aqui está alguma saída, se ajudar a esclarecer alguma coisa:

saída de gpg2 -K:

/home/<username>/.gnupg/pubring.gpg
---------------------------------
sec   rsa4096/AAAAAAAA <date> [SC]
uid         [ultimate] <description of me>
ssb   rsa4096/BBBBBBBB <date> [E]

saída de gpg-connect-agent

> keyinfo --list
S KEYINFO <keygrip associated with AAAAAAAA> D - - - P - - -
S KEYINFO <keygrip associated with BBBBBBBB> D - - - P - - -
OK

saída de gpg2 -v -r <my email> -e testfile

gpg: using PGP trust model
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: This key belongs to us
gpg: reading from 'testfile'
gpg: writing to 'testfile.gpg'
gpg: RSA/AES256 encrypted for: "BBBBBBBB <description of me>"

saída de gpg2 -v -d testfile.gpg

gpg: public key is BBBBBBBB
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: encrypted with 4096-bit RSA key, ID BBBBBBBB, created <date>
      "<description of me>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

15


origem


Você acabou resolvendo isso? Estou tendo exatamente o mesmo problema. - Volker
Nevermind, eu consertei. O necessário para usar gpg-agenteo programa de pinagem precisava ser definido para pinentry-gtk-2. Antes de ser definido para pinentry-gnome3, que existia no meu sistema, mas não funcionou. Eu tive que instalar manualmente pinentry-gtk-2. - Volker


Respostas:


… É claro que o gpg2 não consegue encontrar a chave secreta porque está procurando no arquivo errado.

Não é o  arquivo está olhando.

No GnuPG 1.x (e 2.0), o "secring" costumava ter uma cópia duplicada dos dados públicos do seu keyblock, então era inteiramente independente (e a única diferença entre gpg -k e gpg -K era qual arquivo leria), mas ao mesmo tempo mais difícil para o programa manter.

No GnuPG 2.1, as chaves secretas agora são armazenadas de forma independente - elas são mantidas gpg-agent, que os mantém em ~/.gnupg/private-keys-v1.d/. Então, ambos gpg -k e gpg -K agora tem que ler as informações do OpenPGP do pubring, mas o último também pede gpg-agent sobre quais certificados associaram chaves secretas. Se você estiver usando strace, você deve notar um connect() ligue logo depois de ler o pubring.

Se o GnuPG não migrar automaticamente as chaves, basta importar toda a secring diretamente:

gpg2 --import ~/.gnupg/secring.gpg

Para verificar o conteúdo do agente manualmente:

$ gpg-connect-agent 
> keyinfo --list
S KEYINFO 926145FFCA32B3E6E079A0CF73EA77C40733A349 D - - - P - - -
S KEYINFO BACFB81EAFC864F4AB2926E8B1F55AD579F78D1A D - - - P - - -
S KEYINFO FF3D1DD51B9C79E148CCCEA5F7F3E25EC96048B7 D - - - P - - -
S KEYINFO 4D29EF1460F164CDB11D0FC0247214660ACDD60F D - - - P - - -
S KEYINFO 06B13685B9AA429B9CABCE480930D74B991C8DF0 D - - - P - - -
S KEYINFO B28DB8D045654E8A6A40466A07FCD9E432935E29 D - - - P - - -
Está bem
> / bye
$ 

Estes são "keygrips" - compare-os com o secring do GnuPG:

$ gpg --list-secret-keys --com o keygrip
/home/fred/.gnupg/pubring.kbx
--------------------------------
seg ed25519 2018-08-18 [SC]
      2357E133AD5D24F6CB2C1B0CEF4F7ED27E252632
      Keygrip = 4D29EF1460F164CDB11D0FC0247214660ACDD60F
uid [ultimate] Fred Foobar <fred@example.com>

16



Eu tive o mesmo problema: tentei gerar um uso de chave gpg --gen-key que eu queria usar com gopass. Infelizmente, gopass usa gpg2... gpg2 --import funcionou como um encanto! Obrigado! - andiba
Para mim gpg2 --import ~/.gnupg/pubring.gpg consertou. - Dilawar
Você é meu heroo - Lo-Tan


Eventualmente, eu decidi que o problema era que eu estava usando o Debian Unstable e havia uma incompatibilidade de versão introduzida por um apt-get dist-upgrade. Eu suponho que é por isso que eles chamam de "instável".


1



Eu também tenho no Ubuntu LTS. Depois de mudar do Ubuntu Unity para o GNOME. - nerdoc