[FFmpeg-devel] [PATCH 1/2] avformat/tls_schannel: always decrypt all received data
Hendrik Leppkes
h.leppkes at gmail.com
Wed May 13 01:41:49 EEST 2020
On Wed, May 13, 2020 at 12:35 AM Jan Ekström <jeebjp at gmail.com> wrote:
>
> The dec_buf seems to be properly managed between read calls,
> and we have no logic to decrypt before attempting socket I/O.
> Thus - until now - such data would not be decrypted in case of
> connections such as HTTP keep-alive, as the recv call would
> always get executed first, block until rw_timeout, and then get
> retried by retry_transfer_wrapper.
>
> Thus - if data is received - decrypt all of it right away. This way
> it is available for the following requests in case they can be
> satisfied with it.
> ---
> libavformat/tls_schannel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
> index 4f0badcb8d..7a8842e7fe 100644
> --- a/libavformat/tls_schannel.c
> +++ b/libavformat/tls_schannel.c
> @@ -424,7 +424,7 @@ static int tls_read(URLContext *h, uint8_t *buf, int len)
> c->enc_buf_offset += ret;
> }
>
> - while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK && c->dec_buf_offset < len) {
> + while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK) {
> /* input buffer */
> init_sec_buffer(&inbuf[0], SECBUFFER_DATA, c->enc_buf, c->enc_buf_offset);
>
> --
> 2.26.2
LGTM.
- Hendrik
More information about the ffmpeg-devel
mailing list