Re: [Libevent-users] PATCH: bufferevent_openssl consider_read doesn't drain underlying BE in all cases

[Catalin Patulea <catalinp@xxxxxxxxxx>]

On Mon, Dec 19, 2011 at 5:34 PM, Haseeb Abdul Qadir
<haseebq@xxxxxxxxxxxxxxx> wrote:
> <resending as per Nick's request>
Thanks for resending this on the mailing list.

> SSL_pending() ends up returning 0 in some cases even when the underlying BE's input buffer has data left to consume
This is exactly the condition I was afraid of back when 2aa036f was
being discussed. I was never able to come up with a concrete scenario,
but it seemed conceivable. Note that I was using an OpenSSL bev
layered directly on top of BIO_socket, not looping back over an
underlying bev.

OTOH, if SSL_pending can return 0 with bytes queued in the evbuffer,
then these bytes could just as well be queued in the kernel, when
layering over BIO_socket. So it might be possible to reproduce the
condition with bev_ssl-over-BIO_socket too.

> I've created the patch below and it seems to fix the issue on my end.
> https://github.com/haseebq/libevent/commit/c58d9d8d437d122a8b67d42a6126d81699ec6914
I'm a bit confused by the patch - n_to_read is a number of cleartext
bytes to be read from SSL, right? You're setting it from
evbuffer_get_length, which is a number of encrypted bytes on the
underlying bev (below SSL).

> Ps - I haven't tried to reproduce this bug in a stand alone project yet.
Would you be able to provide a repro, or at least some more in-depth
description of the conditions that prompted the issue to surface?
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.