gnupg 2.1.16 blocs en attente d'entropie

Les versions de gnupg du bloc 2.1.16 (actuellement 2.1.17) n'attendent l'entropie que lors de la première invocation .

Remarque: ce n'est pas une tentative pour générer une clé, juste pour décrypter un fichier et démarrer l'agent.

La première fois que gpg-agent est démarré, directement avec gpg2 file.gpgou en utilisant une application comme pass, Pinentry apparaît et une fois que j'entre ma phrase de passe et que je la frappe, Enterelle se bloque pendant environ 15 secondes.

Tous les appels suivants, dans la fenêtre de default-cache-ttl, sont exécutés immédiatement.

En cours d'exécution en --debug-allmode, la période pendant laquelle le blocage se produit s'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
...

J'ai installé des outils rng pour compléter le pool d'entropie:

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

et par rapport à une machine avec la même version de gnupg qui n'avait pas d'outils rng ou qui n'était pas installé, qui ne présente aucun retard:

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

Il semble donc qu'il y ait suffisamment d'entropie dans la piscine. Cela a été testé sur les noyaux 4.8.13 et 4.9.

Est-ce que gpg utilise un pool différent? Comment puis-je fournir une entropie suffisante ou éliminer le délai de 15 secondes lors du démarrage de l'agent?

Je pense que je sais ce qui se passe. Dans l'agent / gpg-agent.c de gnupg, cette fonction traite les messages 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
}

Cette dernière partie avec npth_usleep a été ajoutée entre 2.1.15 et 2.1.17. Comme cela est compilé conditionnellement si libgcrypt est antérieur à 1.8.0, le correctif simple serait de recompiler gnupg contre libgcrypt 1.8.0 ou version ultérieure… malheureusement, cette version ne semble pas encore exister.

La chose étrange est que ce commentaire sur la lecture de libgcrypt / dev / random n'est pas vrai. Stracing l'agent révèle qu'il lit à partir de / dev / urandom et utilise le nouveau syscall getrandom (2), sans blocage. Il envoie cependant de nombreux messages need_entropy, provoquant le blocage de npth_usleep. La suppression de ces lignes résout le problème.

Je dois mentionner que npth semble être une sorte de bibliothèque multitâche coopérative, et npth_usleep est probablement son moyen de céder, il pourrait donc être préférable de réduire considérablement ce délai, au cas où libgcrypt déciderait de bloquer un jour. (1 ms n'est pas perceptible)