☰

gpg2 работает неоправданно медленно, только когда у агента нет кэшированного пароля

tag-icon • tag-icon encryption gnupg gpg-agent
gpg2 работает неоправданно медленно, только когда у агента нет кэшированного пароля

Недавно мойпроходитьМенеджеру паролей стало требоваться более 45 секунд, чтобы вывести запрос на ввод моего главного пароля gpg-agent, что очень раздражает, когда я пытаюсь войти на веб-сайт и вынужден сидеть и смотреть на запрос пароля в течение минуты.

Я начал проводить некоторые тесты и обнаружил, что, похоже, что-то не так с агентом gpg2. Когда я запускаю gpg1 без настроенного агента, он работает очень быстро (и это включает время ввода моего пароля):

$ time gpg -vvv -d BitBucket.gpg
real    0m2.940s
user    0m0.024s
sys     0m0.004s

Но когда я запускаю gpg2 для того же файла (для использования gpg2 требуется агент), он работает невероятно медленно:

$ time gpg2 -vvv -d BitBucket.gpg
real    0m53.421s
user    0m0.000s
sys     0m0.004s

Но теперь, когда агент кэшировал мой пароль, все снова стало быстро:

$ time gpg2 -vvv -d BitBucket.gpg
real    0m0.126s
user    0m0.004s
sys     0m0.000s

Медленно не расшифровывается — как только наконец появляется запрос пароля, расшифровка происходит за более или менее нормальное время. Просто агенту требуется вечность, чтобы загрузиться и отобразить запрос пароля.

Подробные логи не дают ничего полезного. Вывод выглядит так (нерелевантная и/или конфиденциальная информация заменена на <angle-bracketed text>:

$ gpg2 -vvv -d BitBucket.gpg
gpg: using character set 'utf-8'
<key parameters>
:pubkey enc packet: version 3, algo 1, keyid <X>
        data: [2048 bits]
gpg: public key is <Y>
gpg: using subkey <Y> instead of primary key <Z>
[...here it locks up for 45-ish seconds and then pops up the agent prompt]
gpg: public key encrypted data: good DEK
<key parameters>
:encrypted data packet:
        length: 200
        mdc_method: 2
gpg: using subkey <Y> instead of primary key <Z>
gpg: encrypted with 2048-bit RSA key, ID <Y>, created 2012-03-07
      <ME>
gpg: AES256 encrypted data
<key parameters>
:literal data packet:
        mode b (62), created 1525637737, name="",
        raw data: 151 bytes
gpg: original file name=''
<the content of the password file>
gpg: decryption okay

Я попробовал завершить работу и вручную перезагрузить ее gpg-agentс помощью --log-fileопции, описанной на странице руководства, надеясь получить объяснение того, почему процесс занимает так много времени, но после нескольких операций дешифрования была выведена только одна строка:

2019-07-24 17:49:13 gpg-agent[19648] gpg-agent (GnuPG) 2.1.11 started

Что, очевидно, не очень-то полезно!

Я пробовал менять pinentry-programв своем ~/.gnupg/gpg-agent.conf, но разные графические интерфейсы вели себя одинаково.

я нашелэта тема, но, похоже, речь идет о шифровании (которое, вероятно, заблокировало бы из-за отсутствия случайности, но истинная случайность кажется маловероятной необходимостью для запуска gpg-agent).

Я также нашелнитьо том --check-trustdb, что он медленный и иногда выполняет каждую команду, но я запустил его --check-trustdbсам, и он завершился без ощутимой задержки:

$ time gpg2 -vvv --check-trustdb
real    0m0.009s
user    0m0.008s
sys     0m0.000s

Есть идеи, что я могу попробовать сделать дальше, чтобы разобраться в этом вопросе?

решение1

Проблема на самом деле связана с pinentry, но только косвенно. Это не произойдет с теми pinentry-*реализациями, которые не пытаются запросить демон keyring.

Вероятно, используемый демон и является gnome-keyring-daemonпричиной зависания (кстати, есть и другие реализации брелоков). ИзОтчет об ошибке GPG:

Задержка вызвана тем, что pinentry запрашивает связку ключей GNOME. Добавьте no-allow-external-cacheв gpg-agent.conf, или исправьте установку GNOME, или сообщите о проблеме людям из GNOME.

Вот еще несколько возможных решений:

  • killall gnome-keyring-daemon(будет запущен автоматически при следующем использовании и, возможно, больше не зависнет, перезагрузка не требуется)
  • удаление gnome-keyringпакета, если вы им не пользуетесь

решение2

На моей системе Debian длительная задержка перед тем, как GPG представит запрос на ввод парольной фразы, была вызвана программой pinentry. Она была установлена pinentry-gnome3​​по умолчанию, и ее изменение на, pinentry-cursesпохоже, решило проблему.

Я заметил в вашем вопросе, что вы говорите, что разные GUI вели pinentry-programсебя похоже. Также проблема исчезала после перезагрузки, так что, похоже, вы столкнулись с другой проблемой. Я сталкивался с этой длительной задержкой на нескольких системах на протяжении многих лет, и в некоторых случаях перезагрузка не помогала, поэтому я запишу этот ответ на случай, если кто-то еще сочтет его полезным.

Чтобы исправить это, я выполнил эту команду и выбрал pinentry-curses:

sudo update-alternatives --config pinentry

Для систем, отличных от Debian, вы можете проверить, на какую из них имеется символическая ссылка /usr/bin/pinentry:

ls -l /usr/bin/pinentry

Обновление может выглядеть примерно так:

sudo rm /usr/bin/pinentry
sudo ln -s /usr/bin/pinentry-curses /usr/bin/pinentry

Будьте осторожны, особенно если /usr/bin/pinentryэто не символическая ссылка. В вашем дистрибутиве может быть другой способ сделать это.

После обновления до pinentry-curses(или pinentry-tty) длительная задержка исчезает.

решение3

Озадаченный, я сделал это как пользователь Windows и перезагрузил свой ПК (хотя я использую Linux), и, как ни странно, проблема исчезла. Думаю, что, должно быть, возникла какая-то проблема с другим запущенным процессом.

Я вернусь и обновлю, если это повторится, и я смогу определить, что конкретно было виновником. Записи, перечисленные lsofдля gpg-agent, похоже, не указывают на какие-либо вероятные проблемы, и я дважды проверил, чтобы убедиться, что не было никаких других запущенных агентов или процессов GPG.

Связанный контент