Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

On 2019-02-17 "Torrance, Douglas" wrote: > On 2/17/19 11:49 AM, Andreas Metzler wrote: [...] > > Doug, when there is no actual benefit for this part I would drop > > it. - What do you think? > That sounds good to me. I'll patch it upstream first and let you know > when a new version of the

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

On 2/17/19 11:49 AM, Andreas Metzler wrote: > On 2019-02-13 Nye Liu wrote: >> On February 13, 2019 9:54:12 AM PST, Andreas Metzler >> wrote: >>> I am not sure about the second part of the patch. I understand wmbiff >>> breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started >>>

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

On 2019-02-13 Nye Liu wrote: > On February 13, 2019 9:54:12 AM PST, Andreas Metzler wrote: >> I am not sure about the second part of the patch. I understand wmbiff >> breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started >> to happen recently (with TLS1.3) on blocking sockets.

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

On 2019-02-15 Andreas Metzler wrote: > On 2019-02-13 Nye Liu wrote: >> Also, I'm not sure that the infinite spin wait while() makes sense in >> GNUTLS_E_EAGAIN either. Is some sort of select() more appropriate? > It is the common idiom for this special case. See e.g. GnuTLS' > examples. >

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

On 2019-02-13 Nye Liu wrote: > Also, I'm not sure that the infinite spin wait while() makes sense in > GNUTLS_E_EAGAIN either. Is some sort of select() more appropriate? Hello, It is the common idiom for this special case. See e.g. GnuTLS' examples.

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

Also, I'm not sure that the infinite spin wait while() makes sense in GNUTLS_E_EAGAIN either. Is some sort of select() more appropriate? On February 13, 2019 9:54:12 AM PST, Andreas Metzler wrote: >On 2019-02-13 "Torrance, Douglas" wrote: >> On 12/27/18 3:48 PM, Nye Liu wrote: >>> Package:

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

Probably not, unless some other code change changes the conventional fd to no block. I added it only for symmetry sake. It does not fix any currently known bug. On February 13, 2019 9:54:12 AM PST, Andreas Metzler wrote: >On 2019-02-13 "Torrance, Douglas" wrote: >> On 12/27/18 3:48 PM, Nye

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

On 2019-02-13 "Torrance, Douglas" wrote: > On 12/27/18 3:48 PM, Nye Liu wrote: >> Package: wmbiff >> Version: 0.4.31-1 >> Severity: important >> Tags: upstream patch >> If gnutls_read() or read() report EAGAIN, tlscomm_expect() fails: >> wmbiff/nyet comm: wrote a000 CAPABILITY >> wmbiff/nyet

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

On 12/27/18 3:48 PM, Nye Liu wrote: > Package: wmbiff > Version: 0.4.31-1 > Severity: important > Tags: upstream patch > > If gnutls_read() or read() report EAGAIN, tlscomm_expect() fails: > > wmbiff/nyet comm: wrote a000 CAPABILITY > wmbiff/nyet comm: imap.***.***:993: expecting: * CAPABILITY

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN (TLS 1.3)

Package: wmbiff With TLS 1.3, gnutls will return GNUTLS_E_AGAIN even if the underlying transport socket is a blocking socket. https://gitlab.com/gnutls/gnutls/issues/644#note_123363338

Bug#917467: wmbiff: tlscomm_expect() does not handle EAGAIN or GNUTLS_E_AGAIN

Package: wmbiff Version: 0.4.31-1 Severity: important Tags: upstream patch If gnutls_read() or read() report EAGAIN, tlscomm_expect() fails: wmbiff/nyet comm: wrote a000 CAPABILITY wmbiff/nyet comm: imap.***.***:993: expecting: * CAPABILITY wmbiff/nyet comm: imap.***.***:993: gnutls error