gnupg 2.1.16 блокирует ожидание энтропии

Выпуски gnupg из 2.1.16 (в настоящее время 2.1.17) блокируют ожидание энтропии только при первом вызове .

Примечание: это не попытка сгенерировать ключ, а просто расшифровать файл и запустить агент.

При первом запуске gpg-agent, либо непосредственно, либо с gpg2 file.gpgпомощью приложения, например pass, появляется pinentry, и как только я ввожу свою фразу-пароль и нажимаю на Enterнее, она зависает в течение 15 секунд.

Все последующие вызовы в окне default-cache-ttl выполняются немедленно.

Работая в --debug-allрежиме, период, когда происходит зависание, печатает ¹ :

gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 120 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 120 120
gpg: DBG: chan_6 <- S PROGRESS need_entropy X 30 120
...

Я добавил rng-tools для дополнения энтропийного пула:

cat /proc/sys/kernel/random/entropy_avail 
4094

и сравнивается с машиной с той же версией gnupg, на которой не было установлено rng-tools или hasged , которая не показывает задержки:

cat /proc/sys/kernel/random/entropy_avail
3783

Таким образом, в бассейне, похоже, достаточно энтропии. Это было проверено на ядрах 4.8.13 и 4.9.

Использует ли gpg другой пул? Как я могу обеспечить достаточную энтропию или иным образом устранить 15-секундную задержку при запуске агента?

Я думаю, что знаю, что происходит. В агенте gnupg / gpg-agent.c эта функция обрабатывает сообщения из libgcrypt.

/* This is our callback function for gcrypt progress messages.  It is
   set once at startup and dispatches progress messages to the
   corresponding threads of the agent.  */
static void 
agent_libgcrypt_progress_cb (void *data, const char *what, int printchar,
                             int current, int total)
{
  struct progress_dispatch_s *dispatch;
  npth_t mytid = npth_self ();

  (void)data;

  for (dispatch = progress_dispatch_list; dispatch; dispatch = dispatch->next)
    if (dispatch->ctrl && dispatch->tid == mytid)
      break;
  if (dispatch && dispatch->cb)
    dispatch->cb (dispatch->ctrl, what, printchar, current, total);

  /* Libgcrypt < 1.8 does not know about nPth and thus when it reads
   * from /dev/random this will block the process.  To mitigate this
   * problem we take a short nap when Libgcrypt tells us that it needs
   * more entropy.  This way other threads have chance to run.  */
#if GCRYPT_VERSION_NUMBER < 0x010800 /* 1.8.0 */
  if (what && !strcmp (what, "need_entropy"))
    npth_usleep (100000); /* 100ms */
#endif
}

Последняя часть с npth_usleep была добавлена ​​между 2.1.15 и 2.1.17. Так как это условно компилируется, если libgcrypt старше 1.8.0, простым исправлением будет перекомпиляция gnupg с libgcrypt 1.8.0 или более поздней ... к сожалению, эта версия еще не существует.

Странно то, что комментарий о чтении libgcrypt / dev / random не соответствует действительности. Распределение агента показывает, что он читает из / dev / urandom и использует новый системный вызов getrandom (2) без блокировки. Однако он отправляет много сообщений need_entropy, в результате чего npth_usleep блокируется. Удаление этих строк устраняет проблему.

Я должен отметить, что npth, похоже, является некой кооперативной многозадачной библиотекой, и npth_usleep, вероятно, является ее способом получения, поэтому может быть лучше просто значительно уменьшить эту задержку, на случай, если libgcrypt решит заблокировать когда-нибудь. (1мс не заметно)