[exim-dev] [Bug 2886] Crashes in SMTP delivery attempt follo…

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 2886] Crashes in SMTP delivery attempt following a deferral
https://bugs.exim.org/show_bug.cgi?id=2886

--- Comment #25 from Jeremy Harris <jgh146exb@???> ---
This one is different to Andreas'; the crash is during the verify stage of
TLS establishment. The stacktrace is:

 _gnutls_trust_list_get_issuer
 gnutls_x509_trust_list_get_issuer
 gnutls_x509_trust_list_verify_crt2
 _gnutls_x509_cert_verify_peers
 gnutls_certificate_verify_peers          ^^^
 gnutls_certificate_verify_peers2         ^^^   GnuTLS library
 verify_certificate                       vvv   Exim
 tls_client_start                         vvv
 smtp_setup_conn


>From looking at the GnuTLS source I'm not able to guess what state it's

missing. It's unfortunate that it follows a null pointer rather than
checking and returning an error from the gnutls_certificate_verify_peers2 API
call; I'd call that a bug in GnuTLS.

It's interesting that we had a good TLS conn for the first MX tried, in the
same process. Presumably that leaves GnuTLS in some awkward state. If the
preload support Andreas identified is also relevant to this variant then
the "client CA bundle" is suspect. We're relying on the bundle loaded
during the parent Exim startup (either daemon or cmdline-send), rather than
(as before that commit) loading it afresh for every TLS connection.

A workaround would be to introduce a '$' into the transport
tls_verify_certificates option. "${expand:}" would suffice, added to the
existing; this is just to make exim think the option value might vary so must
not be cached.

I'd suggest raising a bug against GnuTLS for this.
Testing with a range of different GnuTLS versions might also be useful.

--
You are receiving this mail because:
You are on the CC list for the bug.