I was perusing through libraries/libldap/tls.c deciding whether it was safe
to use non-blocking I/O (i.e. polling the underlying fd) w/ SSL in a client.
If the underlying BIO is non-blocking, SSL_read() will also return
when the underlying BIO could not satisfy the needs of SSL_read() to
continue the operation. In this case a call to SSL_get_error(3) with
the return value of SSL_read() will yield SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. As at any time a re-negotiation is possible, a
call to SSL_read() can also cause write operations!
-- man page SSL_read(3)
In tls.c:sb_tls_read and tls.c:sb_tls_write only one of SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE is checked after the SSL_read or SSL_write.
Does anybody know if this condition is handled by some other part of the
code? Or alternatively if there is a justified assumption that it could
never happen?
FWIW, tls.c:update_flags seems to miss the boat, too.
In my code I only poll on a read event, since it seems that OpenLDAP does
its writes blocking. However, SSL throws a monkey wrench into this
precarious arrangement.