Bug#338319: [338319] exim4: no entropy on starting

[Ben Collins]

On Sat, 2006-10-07 at 18:51 +0200, Marc Haber wrote:
> On Sun, Aug 27, 2006 at 11:09:55PM +0200, Ben Collins wrote:
> > IMO, the best way to handle this would be just like sshd. It does not
> > generate an RSA on first connection, it does it when the package is
> > installed.
> > 
> > Either generate this initial key at install, or detect that TLS is
> > enabled in the init script and generate it if doesn't exist.
> 
> I am not sure whether this is going to work. Generating dh_parameters
> is very fast if enough entropy is available, so in case that enough
> entropy is available, we don't need to bother and can have exim
> generate them on first connection.
> 
> If not enough entropy is available, generating dh_parameters is going
> to take a looooooong time, so we'd either have a long delay on package
> installation (in which case exim is not going to be available any
> earlier), or we'd send the dh_parameters generation in the background
> which will cause exim to generate the dh_parameters on first
> connection, resulting in exim being unavailable until the
> dh_parameters have been. built.
> 
> Frankly, I don't see a gain in generating the dh_parameters on package
> installation or from the init script. Am I missing something?

The benefit is that during installation, people expect things to be
down. When it's installed, people don't expect their smtp server to
start timing because of lack of entropy.

I had to manually create entropy while an smtp connection was made to my
server, hoping I did it in time, before the smtp connection timed out,
in order for it to start working. I shouldn't have to jump through
hoops. If I installed the package, and it asked for entropy then (or did
it when exim first started up) then you know there's a delay, and you
know why, and it gives you the opportunity to create this entropy
without worrying about things like an smtp connection timing out.

The bad thing about it happening when first connection occurs is that if
the smtp connection times out, all of that entropy it got already is
thrown away. The next connection starts the process again, most likely
with zero entropy at that point.

You should not have to jigger a setup like this.