Dear Maintainer,

When running tests for python-gnupg (e.g. at build time) I use the
option --debug-quick-random to use /dev/urandom instead of /dev/random
to be able to complete the tests in a reasonable time (as it is
generating keys that will be dropped later).

With gnupg 1.4 the corresponding option --quick-random had the desidered
effect, but since the move gnupg 2.1 this seems to be ignored, to the
serious detriment of build times (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874720 )

This can be reproduced by monitoring
/proc/sys/kernel/random/entropy_avail while generating keys, especially
on a machine without entropy generating tokens or the like.

Please let me know if I'm using the option in the wrong way, in which
case this would become a whishlist bug asking for better documentation.

Your problem is that the keys are generated by gpg-agent.  Thus you
would need to use --debug-quick-random in gpg-agent.conf.  However, this
is not possible because we need to switch libgcrypt into quick random
mode as early as possible and thus gpg-agent detects it only when given
on the command line.  Now, gpg-agent is started on demand by gpg and
thus we need a way to put it on the command line.  If you put this into
the gpg.conf

  agent-program /usr/bin/gpg-agent|--debug-quick-random

the agent will be started by gpg with an additional option of
--debug-quick-random.  The use of the pipe symbol is an ugly kludge
but does its work.  See gnupg/tests/openpgp/defs.scm for the other
options we use for the gnupg internal regression tests.

Another way is to start the agent first.  The GPGME test suite does this
and uses the script gpgme/tests/start-stop-agent.

Yet another way is to gobally do away with /dev/random and use
/dev/urandom (or the getrandom syscall).  With Libgcrypt 1.8 this can be
done by putting

  only-urandom

into /etc/gcrypt/random.conf.  That might in fact be a good idea for
builder boxes.


Salam-Shalom,

   Werner

Thanks for your quick answer!

This probably gives me a solution for python-gnupg (I'm looking at the
options to see what's easier to implement and will do another upload).

As for this bug, I don't know if there is a place to add this info as
documentation, otherwise for me it can just be closed.