gnupg 2.1.16 bloques esperando la entropía

Las versiones de gnupg del bloque 2.1.16 (actualmente 2.1.17) esperan la entropía solo en la primera invocación .

Nota: este no es un intento de generar una clave, solo descifrar un archivo e iniciar el agente.

La primera vez que se inicia gpg-agent, ya sea directamente con gpg2 file.gpgo usando una aplicación como pass, aparece pinentry y una vez que ingreso mi frase de contraseña y la presiono Enterse cuelga por alrededor de 15 segundos.

Todas las llamadas posteriores, dentro de la ventana de default-cache-ttl, se ejecutan inmediatamente.

Ejecutando en --debug-allmodo, el período donde se produce el bloqueo imprime ¹ :

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
...

Instalé rng-tools para complementar el grupo de entropía:

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

y en comparación con una máquina con la misma versión de gnupg que no tenía rng-tools o hasged instalado, que no muestra demora:

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

Entonces parece haber suficiente entropía en el grupo. Esto se probó en los núcleos 4.8.13 y 4.9.

¿Gpg utiliza un grupo diferente? ¿Cómo puedo proporcionar suficiente entropía o eliminar el retraso de 15 segundos al iniciar el agente?

Creo que sé lo que está pasando. En el agente / gpg-agent.c de gnupg, esta función procesa los mensajes de 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
}

La última parte con npth_usleep se agregó entre 2.1.15 y 2.1.17. Dado que esto se compila condicionalmente si libgcrypt es anterior a 1.8.0, la solución directa sería recompilar gnupg contra libgcrypt 1.8.0 o posterior ... desafortunadamente esa versión parece no existir todavía.

Lo extraño es que ese comentario sobre libgcrypt reading / dev / random no es cierto. El enderezado del agente revela que está leyendo desde / dev / urandom y está usando la nueva llamada al sistema getrandom (2), sin bloqueo. Sin embargo, envía muchos mensajes need_entropy, lo que hace que npth_usleep se bloquee. Eliminar esas líneas soluciona el problema.

Debo mencionar que npth parece ser algún tipo de biblioteca cooperativa multitarea, y npth_usleep es probablemente su forma de rendir, por lo que podría ser mejor reducir significativamente ese retraso, en caso de que libgcrypt decida bloquear algún día. (1 ms no se nota)