On 2019-02-13 "Torrance, Douglas" <dtorra...@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'