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.
