У меня gpg-agent работает с кешированной парольной фразой в течение часа или около того. Я зашифровываю пароли к своей учетной записи электронной почты для offlineimap синхронизации оффлайн-карты IMAP, и сценарий передает пароли, расшифровывая их из файла, зашифрованного GPG.

Так как я запускаю offlineimap с systemd, поскольку это задание cron, оно, естественно, вызывает программу pinentry и запрашивает пароль. Мне было интересно, есть ли способ программно подтвердить, понадобится ли gpg-agent пароль, чтобы я мог запросить информацию и изящно выйти из задания systemd/cron, если требуется интерактивный ввод пароля.

Кто-нибудь делал это раньше?

|источник

2 ответа2

1

У меня просто есть подобный план, чтобы периодически получать / синхронизировать электронные письма, используя mbsync и cron . Пароли управляются pass , который использует GnuPG для шифрования конфиденциальных данных.

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

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

Я думаю, что mbsync cron синхронизирует мои электронные письма, когда gpg может просто расшифровать пароль для pass не вызывая gpg-agent для запроса пароля, иначе задание cron просто завершится.

Я обнаружил, что GnuPG имеет параметр --pinentry-mode , который может иметь значения:

  • default : использовать значение по умолчанию для агента, которое является ask .
  • ask : форсировать использование Пентри.
  • cancel : эмулировать использование кнопки отмены Пинтри.
  • error : Вернуть ошибку Pinentry (`` No Pinentry '').
  • loopback : перенаправить запросы Pinentry вызывающей стороне. Обратите внимание, что в отличие от Pinentry, пользователю не предлагается снова вводить неверный пароль.

Следовательно, я могу явно отключить использование пинентри, передав --pinentry-mode cancel или --pinentry-mode error , и разрешив gpg попытаться подписать / расшифровать сообщение. Если это удалось, то gpg-agent уже имеет кешированную фразу-пароль и не будет отображаться в диалоговом окне ввода ; в противном случае проверка знака / дешифрования просто не удалась.

Например:

Когда gpg-agent не кэширует нужную ключевую фразу:

$ echo "test" | \
  gpg2 --sign --batch --no-tty --pinentry-mode error \
       --local-user <you@example.com> -o /dev/null

# Return code: 2
# OUTPUT:
# gpg: signing failed: No pinentry
# gpg: signing failed: No pinentry

Когда gpg-agent уже кеширует парольную фразу, та же команда будет выполнена успешно и вернет код состояния 0.

Если я использую --pinentry-mode cancel , то gpg завершается ошибкой с отменой Operation cancelled .

|источник
0

Я не знаю наверняка, но мне интересно, имеет ли смысл иметь такую опцию, потому что она легко может быть использована неправильно, например:

#!/bin/sh
if gpg_ready_to_work_without_pinentry; then
    do_something_malicious_with_the_key;
fi

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .