gnupg 2.1.16 Blöcke warten auf Entropie

Releases von GnuPG von 2.1.16 (derzeit 2.1.17) Block wartet auf Entropie nur auf den ersten Aufruf .

Hinweis: Dies ist kein Versuch, einen Schlüssel zu generieren, sondern nur eine Datei zu entschlüsseln und den Agenten zu starten.

Das erste Mal, wenn gpg-agent gestartet wird, entweder direkt mit gpg2 file.gpgoder unter Verwendung einer Anwendung wie pass, erscheint pinentry und sobald ich meine Passphrase eingebe und sie drücke Enter, hängt sie ungefähr 15 Sekunden lang .

Alle nachfolgenden Aufrufe im Fenster des Standard-Cache-ttl werden sofort ausgeführt.

Im --debug-allModus wird in dem Zeitraum, in dem der Hang auftritt, ¹ gedruckt :

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

Ich habe rng-tools installiert , um den Entropiepool zu ergänzen:

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

und verglichen mit einer Maschine mit der gleichen Version von gnupg, auf der keine rng-tools oder hasged installiert waren, zeigt dies keine Verzögerung:

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

Es scheint also genügend Entropie im Pool zu geben. Dies wurde auf den Kerneln 4.8.13 und 4.9 getestet.

Verwendet gpg einen anderen Pool? Wie kann ich eine ausreichende Entropie bereitstellen oder die Verzögerung von 15 Sekunden beim Starten des Agenten auf andere Weise beseitigen?

Ich glaube ich weiß was los ist. In gnupgs agent / gpg-agent.c verarbeitet diese Funktion Nachrichten von 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
}

Dieser letzte Teil mit npth_usleep wurde zwischen 2.1.15 und 2.1.17 hinzugefügt. Da dies bedingt kompiliert wird, wenn libgcrypt älter als 1.8.0 ist, besteht die einfache Lösung darin, gnupg gegen libgcrypt 1.8.0 oder höher neu zu kompilieren. Leider scheint diese Version noch nicht zu existieren.

Das Seltsame ist, dass dieser Kommentar zum Lesen von libgcrypt / dev / random nicht wahr ist. Wenn Sie den Agenten straffen, wird angezeigt, dass er aus / dev / urandom liest und den neuen getrandom (2) -Syscall verwendet, ohne ihn zu blockieren. Es werden jedoch viele Need_entropy-Nachrichten gesendet, wodurch npth_usleep blockiert wird. Das Löschen dieser Zeilen behebt das Problem.

Ich sollte erwähnen, dass npth eine Art kooperative Multitasking-Bibliothek zu sein scheint, und npth_usleep ist wahrscheinlich der Weg, um nachzugeben. Daher ist es möglicherweise besser, diese Verzögerung nur erheblich zu reduzieren, falls libgcrypt beschließt, eines Tages zu blockieren. (1ms fällt nicht auf)