Um 19:57 Uhr am 30.01.06 schrieb Florian Weimer: >> I just want to point out that current exim4 packages (>=4.52-2) do >> _not_ remove /var/spool/exim4/gnutls-params unconditionally, but only >> after successfully re-generating a replacement *offline* using >> certtool (if certtool is available). > Yes, I discovered that too. This means that this bug is likely a > duplicate of #285371. (Provided that the submitter does not have > certtool installed.) > > Sven, if you do not patch anything, but remove the "rm -f > /var/spool/exim4/gnutls-params" from the daily cron job, does that fix > things for you once the file has been generated?
Here is what I did: 1) Downgraded exim4, exim4-base, exim4-config and exim4-daemon-heavy to the version from Sarge (4.50-8). 2) Waited for the gnutls-params file to reappear. 3) (in another ssh session) while true; do cat /proc/sys/kernel/random/entropy_avail; sleep 0.2; done 4) waited until the entropy pool refilled itself 5) used an external server to send an encrypted mail to me: 3368 3372 129 140 140 So, conclusion: No the problem is not the gnutls-params file, but exim4 using nearly each and every bit of entropy for a _single_ mail. Using exim4+openssl does not cause this massive drain of entropy. (I have yet to test your patch to see if this also relieves the situation.) Of course, regenerating the gnutls-params file every day depletes the pool even more and my increase the severity of the problem on machines with a low entropy regain rate. Grüße, Sven. -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ Achtung, neue Mail-Adresse: [EMAIL PROTECTED]