Is #285371 really an exim problem, or is it gnutls failing?
Hi,
bug #285371 is about exim blocking for extended periods of time when
re-generating some gnutls keys. strace shows that the application
blocks when trying to read from /dev/random, most probably because of
available entropy being exhausted.
The fix mentioned in the bug report is to regenerate the gnutls keys
asynchronously and only to exchange them for the exim processes after
they have been successfully generated, preventing exim from blocking.
I am, however, concerned about a tool potentially hanging on to
/dev/random for extended periods of time, sucking in all available
entropy, draining it from being available to other applications which
might be in more dire need of entropy.
Wouldn't it probably be a better idea to have gnutls read entropy from
/dev/urandom instead? I don't think it is a good idea to have
functions blocking for extended periods of time.
So I am inclined to have the bug report reassigned to gnutls,
suggesting using /dev/urandom instead of /dev/random. A second
possibility would be extending the gnutls-params exchanger binary with
a timeout so that it aborts if generation takes longer than - say - 60
seconds. That way it could be avoided to have the program suck up all
available entropy for longer than the timeout.
May I ask for your opinion?
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: