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 

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: 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
>> and released a new version of wmbiff [2].
>> Andreas, I've pushed a new Debian package to git [3].  Would you be
>> to review and sponsor?
>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
>second part, this is in the else of "if (scs->tls_state)", so, afaiui
>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'

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to