[exim-dev] [Bug 2174] callout timeout in recipient verify ca…

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: admin
Data:  
Para: exim-dev
Temas antigos: [exim-dev] [Bug 2174] New: callout timeout in recipient verify can result in the the lost of the TLS incoming connexion
Asunto: [exim-dev] [Bug 2174] callout timeout in recipient verify can result in the the lost of the TLS incoming connexion
https://bugs.exim.org/show_bug.cgi?id=2174

Git Commit <git@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |git@???


--- Comment #17 from Git Commit <git@???> ---
Git commit:
https://git.exim.org/exim.git/commitdiff/f1fed05bfbcf83b7d504ea68d136c4a923d070ea

commit f1fed05bfbcf83b7d504ea68d136c4a923d070ea
Author:     Jeremy Harris <jgh146exb@???>
AuthorDate: Sat Jan 27 15:03:01 2018 +0000
Commit:     Jeremy Harris <jgh146exb@???>
CommitDate: Sat Jan 27 15:03:01 2018 +0000


    GnuTLS: fix to ignore timeout on unrelated callout connection.  Bug 2174
---
 doc/doc-txt/ChangeLog | 6 ++++++
 src/src/tls-gnu.c     | 5 ++---
 2 files changed, 8 insertions(+), 3 deletions(-)


diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog
index 7d577db..bac937e 100644
--- a/doc/doc-txt/ChangeLog
+++ b/doc/doc-txt/ChangeLog
@@ -71,6 +71,12 @@ JH/13 Bug 2229: Fix cutthrough routing for nonstandard port
numbers defined by
       routers.  Previously, a multi-recipient message would fail to match the
       onward-connection opened for the first recipient, and cause its closure.


+JH/14 Bug 2174: A timeout on connect for a callout was also erroneously seen
as
+      a timeout on read on a GnuTLS initiating connection, resulting in the
+      initiating connection being dropped.  This mattered most when the
callout
+      was marked defer_ok.  Fix to keep the two timeout-detection methods
+      separate.
+


 Exim version 4.90
 -----------------
diff --git a/src/src/tls-gnu.c b/src/src/tls-gnu.c
index 5c9fd39..3a45999 100644
--- a/src/src/tls-gnu.c
+++ b/src/src/tls-gnu.c
@@ -2364,10 +2364,8 @@ DEBUG(D_tls) debug_printf("about to
gnutls_handshake\n");
 sigalrm_seen = FALSE;
 alarm(ob->command_timeout);
 do
-  {
   rc = gnutls_handshake(state->session);
-  } while ((rc == GNUTLS_E_AGAIN) ||
-      (rc == GNUTLS_E_INTERRUPTED && !sigalrm_seen));
+while (rc == GNUTLS_E_AGAIN || rc == GNUTLS_E_INTERRUPTED && !sigalrm_seen);
 alarm(0);


if (rc != GNUTLS_E_SUCCESS)
@@ -2483,6 +2481,7 @@ ssize_t inbytes;
DEBUG(D_tls) debug_printf("Calling gnutls_record_recv(%p, %p, %u)\n",
state->session, state->xfer_buffer, ssl_xfer_buffer_size);

+sigalrm_seen = FALSE;
if (smtp_receive_timeout > 0) alarm(smtp_receive_timeout);
inbytes = gnutls_record_recv(state->session, state->xfer_buffer,
MIN(ssl_xfer_buffer_size, lim));

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