gpg2: brak tajnego klucza

Używam enigmail od ponad roku bez problemu, a dziś to nie działa.

Znalazłem następujący interesujący fakt:

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

Więc coś jest nie tak z gpg w wersji 2 na moim komputerze.

Doprowadziło mnie to do tego, że:

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

To wydaje się być przyczyną problemu ... oczywiście gpg2nie można znaleźć tajnego klucza, ponieważ szuka on niewłaściwego pliku.

Jak mogłem gpg2ponieść porażkę, gdy moje gpgprace działały dobrze? Nie widzę żadnych opcji określających, skąd są odczytywane tajne klucze.

Czy ktoś ma jakieś pomysły?

Odpowiedź na @grawity :

Dziękuję, doceniam twoją pomoc. Pobiegłem stracei widzę, o czym mówisz.

Jednak nawet po tym, jak gpg2 --import ...nie widzę żadnej różnicy w zachowaniu. Mogę go uruchomić tylko wtedy, gdy uruchomię ponownie (bez uruchamiania gpg-agent), uruchom gpg2 --import ..., a następnie uruchom gpg2 --decrypt .... Po tej sekwencji thunderbird + enigmail również zachowuje się ładnie. Jednak po około 15 minutach (zgaduję, że hasło, które wprowadziłem w celu odszyfrowania wygasło), gpg-agentto wraca do swojego starego zachowania. Ta sekwencja jest powtarzalna.

Oto kilka danych wyjściowych, jeśli to pomaga wyczyścić cokolwiek:

wyjście gpg2 -K:

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

wyjście z gpg-connect-agent

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

wyjście z 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>"

wyjście z 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

… Oczywiście gpg2 nie może znaleźć tajnego klucza, ponieważ szuka niewłaściwego pliku.

To nie jedyny plik, na który patrzy.

W GnuPG 1.x (2,0), to „SECRING” używane mieć duplikat danych publicznych Twojego klucz mechaniczny, jak również, więc to był całkowicie samowystarczalny (a jedyna różnica między gpg -ki gpg -Kbył plik, który by to czytać) , ale jednocześnie trudniejsze do utrzymania przez program.

W GnuPG 2.1 tajne klucze są teraz przechowywane niezależnie - są one obsługiwane przez gpg-agent , który je utrzymuje ~/.gnupg/private-keys-v1.d/. Więc zarówno teraz, jak gpg -ki gpg -Kteraz, musimy przeczytać informacje o OpenPGP z publikacji, ale ta ostatnia dodatkowo pyta gpg-agent o to, które certyfikaty są powiązane z tajnymi kluczami. Jeśli używasz strace , powinieneś zauważyć connect()połączenie zaraz po przeczytaniu publikacji.

Jeśli GnuPG nie przeprowadził automatycznej migracji kluczy, po prostu zaimportuj cały mechanizm zabezpieczeń bezpośrednio:

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

Aby ręcznie sprawdzić zawartość agenta:

$ 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 - - -
dobrze
> / Bye 
$

Oto „uchwyty klawiszy” - porównaj je z zabezpieczeniami GnuPG:

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

W końcu zdecydowałem, że problem polega na tym, że korzystam z Debian Unstable i wprowadzono niedopasowanie wersji wprowadzone przez apt-get dist-upgrade. Przypuszczam, że dlatego nazywają to „niestabilnym”.