[Monotone-devel] nvm.stripped versus botan

[Zack Weinberg]

I noticed a severe slowdown in the time for nvm.stripped to run the
testsuite (from five to twelve minutes on my big beefy quad-core
machine) which *seems* to be all down to initializing botan's RNG.  In
botan 1.8.0, the AutoSeeded_RNG that's created when you run
Botan::RandomNumberGenerator::make_rng() uses every entropy source
that's compile-time available.  In particular, on Linux it uses
/dev/random *and* EGD *and* the Unix_EntropySource one that runs a
whole bunch of system status utilities.  This adds a tenth of a second
to every "mtn" invocation, which really hurts in the testsuite.

Jack  - Can we get this fixed in botan?  It seems to me that the Right
Thing is for each entropy source to report whether it works on a
particular system, and then for the RNG object to use only the first
one that works.  Thus, if we've got /dev/random we don't even look for
EGD, if we've got EGD we don't try the programs, and so on.

Also, I'm confused about the use of high-resolution timers as entropy
sources -- it seems like they don't belong, or at least ought to be
subordinated to the "real" entropy sources.  Maybe the idea is to
avoid dipping into the more expensive entropy pools as much?  Only I'm
not sure I trust rdtsc (e.g.) to give entropy *at all*...

Monotone folks - Do we really need to keep backward compatibility with
botan pre-1.7.7?  This would be much easier to work around in the
application if I could junk the old interfaces  Also, do we really
need cryptographic entropy in mkstemp.cc?  Currently *every
invocation* of monotone_mkstemp is initializing a new RNG object.
Fortunately it's only called from LUAEXT(mkstemp), but still...

zw