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

[Andreas Metzler]

On 2019-02-13 "Torrance, Douglas" <dtorrance at piedmont.edu> 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  comm: imap.***.***:993: expecting: * CAPABILITY
>> wmbiff/nyet  comm: imap.***.***:993: gnutls error reading: Resource temporarily unavailable, try again.
>> wmbiff/nyet  imap4: unable to query capability stringwmbiff/nyet  comm: wrote a002 LOGOUT
>> wmbiff/nyet  comm: imap.***.***:993: closing.

> Thanks for the bug report and patch!  I submitted the patch upstream [1] 
> and released a new version of wmbiff [2].

> Andreas, I've pushed a new Debian package to git [3].  Would you be able 
> to review and sponsor?

Hello,

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.

What I do not get from my rudimentary understanding C programmimg is the
second part, this is in the else of "if (scs->tls_state)", so, afaiui for
non-encrypted connections. Is the change necessary there at all, is it
the right thing to retry read on EAGAIN then?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'