[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interoperability issues (Debian Bug #348046)
From: |
Simon Josefsson |
Subject: |
Re: Interoperability issues (Debian Bug #348046) |
Date: |
Tue, 26 Feb 2008 18:09:28 +0100 |
User-agent: |
Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) |
Marc Haber <address@hidden> writes:
>> (EE) Vincent Lefevre says (Message 120) that the first message each
>> morning fails with this error message too.
>>
>> One theory here could be some firewall acting up the first time every
>> morning, what do you think? As Andreas Metzler says in message 125,
>> there is nothing in the entropy code that could explain this. The error
>> message is also not entropy related.
>
> This is #467158, http://bugs.debian.org/467158
>
> This is interesting since it is the only issue in this report where
> the exim giving the error message is the _client_. My guess is that
> the gnutls-params file was just removed and the first sending exim
> tried to re-generate the gnutls-params, which is a blocking operation.
>
> This has been mitigrated in a later Debian exim package by (a)
> disabling the RSAEXPORT ciphers and (b) doing the recalculation of the
> gnutls-params asynchronously and only replacing the old file with the
> new after the params were fully calculated. Submitter pined.
Generally, I am curious what the justification of re-generating the
gnutls-params are in the first place? Doesn't "gnutls-params" refer to
the diffie-hellman parameters? I recall that some people say you never
need to regenerate them at all, and I haven't seen anyone recommend that
you do regenerate them. I haven't seen any other gnutls application
servers generate diffie-hellman parameters.
>> > (F) Vincent Lefevre saying (Message 130), that outgoign messages also
>> > reduce entropy.
>>
>> Which may be true.
>
> Which _is_ true. Is that also addressed by saving the random seed?
Yes. Each encryption of application data needs one byte of random
(urandom quality) data, for random message length padding.
>> > (G) Andrew McGlashan finding it impossible to connect to gnutls-serv
>> > with incredimail (giving debug output in Message 224).
>
> Incredimail issue, it cannot handle a client certificate request. Can
> be remedied by disabling client certificates in exim. Same issue
> happens of course when exim is compiled against OpenSSL, definetely
> not a GnuTLS issue.
Btw, how do you disable client certificate requests in exim? Is it
possible without recompilation?
/Simon