从2.1.16(当前为2.1.17)发布的gnupg块仅在首次调用时等待熵。
注意:这不是尝试生成密钥,只是为了解密文件并启动代理。
第一次启动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-tools来补充熵池:
cat /proc/sys/kernel/random/entropy_avail
4094
并与没有安装rng-tools或没有安装过ghgn的具有相同gnupg版本的计算机相比,该计算机没有延迟:
cat /proc/sys/kernel/random/entropy_avail
3783
因此,池中似乎有足够的熵。这在内核4.8.13和4.9上进行了测试。
gpg是否使用其他池?启动代理时,如何提供足够的熵,或者消除15s的延迟?
我想我知道发生了什么事。在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
}
在2.1.15和2.1.17之间添加了最后一个带有npth_usleep的部分。由于如果libgcrypt早于1.8.0,则可以有条件地对其进行编译,因此直接解决方案是针对libgcrypt 1.8.0或更高版本重新编译gnupg。不幸的是,该版本似乎还不存在。
奇怪的是,关于libgcrypt读取/ dev / random的评论是不正确的。跟踪代理可显示它正在从/ dev / urandom中读取并使用新的getrandom(2)syscall,而不会阻塞。但是,它确实发送了许多need_entropy消息,导致npth_usleep阻塞。删除这些行可解决此问题。
我应该提到,npth似乎是某种协作式多任务库,并且npth_usleep可能是它的产生方式,因此最好是大幅减少该延迟,以防万一libgcrypt决定阻止某天。(1ms不太明显)
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句