☰

gnupg 2.1.16 阻止等待熵

tag-icon • tag-icon linux-kernel encryption gpg
gnupg 2.1.16 阻止等待熵

发布的格努普格从2.1.16（当前2.1.17）开始阻塞等待熵仅在第一次调用时。

注：这个不是尝试生成密钥，只是为了解密文件并启动代理。

第一次启动 gpg-agent 时，无论是直接使用gpg2 file.gpg还是使用诸如 之类的应用程序pass，pinentry 都会出现，一旦我输入密码并点击Enter它，它就会挂起大约 15 秒。

default-cache-ttl 窗口内的所有后续调用都会立即执行。

在模式下运行--debug-all，发生挂起的时间段打印1：

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工具补充熵池：

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

并与具有相同版本 gnupg 但没有 rng-tools 的机器进行比较哈吉德已安装，没有延迟：

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

所以有出现池中有足够的熵。这是在内核 4.8.13 和 4.9 上进行测试的。

gpg 使用不同的池吗？如何提供足够的熵，或者以其他方式消除启动代理时 15 秒的延迟？


1. 的完整的调试日志。

答案1

我想我知道发生了什么事。在gnupg的agent/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，这是有条件编译的，因此直接的修复方法是针对 libgcrypt 1.8.0 或更高版本重新编译 gnupg……不幸的是，该版本似乎还不存在。

奇怪的是，关于 libgcrypt 读取 /dev/random 的评论是不正确的。跟踪代理发现它正在从 /dev/urandom 读取并使用新的 getrandom(2) 系统调用，而不会阻塞。然而，它确实发送了许多 need_entropy 消息，导致 npth_usleep 阻塞。删除这些行可以解决问题。

我应该提到 npth 似乎是某种协作多任务库，而 npth_usleep 可能是它的屈服方式，因此最好显着减少延迟，以防万一 libgcrypt 决定阻止某天。 （1ms不明显）

相关内容