Andreas Metzler <[EMAIL PROTECTED]> writes: > On 2008-01-31 Werner Koch <[EMAIL PROTECTED]> wrote: >> On Wed, 30 Jan 2008 19:20, [EMAIL PROTECTED] said: > >>> Any obvious breakage? Exim does not use any threading. I have not >>> included an gcry_check_version(NULL) since I thought gcry_control() >>> would fail as reliably as gcry_check_version() would, if gcrypt was > >> Better insert a gcry_check_version because this is the safe way to >> initialize gcrypt. The initialization is also done with most other >> gcry_control calls but that is a failsafe feature. Explicitly >> initialization is better (you don't need to check the return code, just >> call it.) > > Hello, > > we still seem have not been able to find a really working solution, > this patch > <http://svn.debian.org/wsvn/pkg-exim4/exim/trunk/debian/patches/65_saverandomseed.dpatch?op=file&rev=0&sc=0> > causes crashes in exim. > > Quoting Marc Haber in http://bugs.exim.org/show_bug.cgi?id=654 > | However, the secondary MX (which delivers some spam to the primary MX) noted > | that the primary box had become unreliable in TLS: > | 2008-01-30 14:51:21 1JKDKT-0003ME-AG Remote host mailgate.zugschlus.de > | [85.214.68.41] closed connection in response to STARTTLS > | > | When this happened (a couple of times per hour), I didn't get any > | atypical log entries on mailgate. > | > | This was a repeating, but intermittent failure since mailgate > | continued to work normally, and STARTTLS was successful most of the > | time. > [...] > | Going back to the same exim sans the random-seed patch, entropy > | average went back to 200, but the STARTTLS failures vanished. > > We have tried to isolate what actually breaks, by only applying parts > of the patch (e.g setting up dthe seed file, but not updating it.), > but it looks like the mere presence of > gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename) > causes the crashes.
Did you follow Werner's suggestion to the patch? I.e., to call gcry_check_version to initialize libgcrypt properly. > I am really wondering whether using the experimental daemon might be > worthwile, there does not seem to be much cost involved, and > /dev/(u)random has not got any policy controls either. I think doing whatever it takes to make libgcrypt return useful amounts of entropy would be a good thing. Forcing every application to set a seed file is quite costly maintenance and documentation wise, so running one libgcrypt-specific daemon may be simpler. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
