gpg2: немає секретного ключа

Я використовую enigmail більше року без проблем, і сьогодні це не працює.

Я виявив такий цікавий факт:

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

Тож щось порушено з gpg версією 2 на моїй машині.

Це змусило мене побачити, що:

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

Здається, це корінь проблеми ... звичайно, gpg2не можна знайти секретний ключ, тому що він шукає неправильний файл.

Як я можу gpg2зазнати невдачі, коли мої gpgроботи прекрасні? Я не бачу жодних варіантів, щоб визначити, звідки читаються секретні ключі.

У когось є ідеї?

Відповідь на @grawity :

Дякую, я вдячний за вашу допомогу. Я побіг strace, і бачу, про що ти говориш.

Однак навіть після того, як gpg2 --import ...я не бачу різниці в поведінці. Я можу змусити його працювати лише в тому випадку, якщо перезавантажую (не запускаючи gpg-агент), запускаю gpg2 --import ..., а потім запускаю gpg2 --decrypt .... Після цієї послідовності thunderbird + enigmail також добре поводиться. Однак через 15 хвилин або більше (гадаю, термін дії пароля, який я ввів для розшифровки, минув), gpg-agentповертаємося до своєї старої поведінки. Ця послідовність повторювана.

Ось ось деякий результат, якщо він допомагає очистити що-небудь:

вихід gpg2 -K:

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

вихід gpg-connect-agent

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

вихід 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>"

вихід 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

... звичайно, gpg2 не може знайти секретний ключ, оскільки він шукає неправильний файл.

Це не єдиний файл, який він дивиться.

У GnuPG 1.x (та 2.0) "secring" використовував також копію публічних даних вашого клавіатурного блоку, тому він був повністю автономним (і єдина різниця між тим, gpg -kі gpg -Kякий саме файл він читав). , але в той же час складніше підтримувати програму.

У GnuPG 2.1 секретні ключі тепер зберігаються незалежно - вони підтримуються gpg-агентом , який зберігає їх ~/.gnupg/private-keys-v1.d/. Отже, gpg -kі gpg -Kтепер, і зараз доводиться читати інформацію OpenPGP з виводу, але останній додатково запитує gpg-агент про те, які сертифікати мають пов’язані секретні ключі. Якщо ви користуєтеся страйком , вам слід помітити connect()дзвінок одразу після прочитання пубрингу.

Якщо GnuPG не перемістив автоматично ключі, просто імпортуйте весь секрінг безпосередньо:

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

Щоб перевірити вміст агента вручну:

$ gpg-connect-agent 
> keyinfo - список
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 - - -
добре
> / до побачення 
$

Це "клавіші" - порівняйте їх із секцією GnuPG:

$ gpg - список-секретні ключі --з клавішним ключем
/home/fred/.gnupg/pubring.kbx
--------------------------------
сек ed25519 2018-08-18 [SC]
      2357E133AD5D24F6CB2C1B0CEF4F7ED27E252632
      Keygrip = 4D29EF1460F164CDB11D0FC0247214660ACDD60F 
uid [остаточний] Фред Фобар <fred@example.com>

Врешті-решт, я вирішив, що проблема в тому, що я використовую Debian Unstable, і з’явилася невідповідність версій, введена програмою an apt-get dist-upgrade. Я гадаю, саме тому вони називають це "Нестабільним".