| Message ID | 20170127173158.2023-1-kabel@blackhole.sk |
|---|---|
| State | Superseded |
| Headers | show |
On 27/01/17 17:31, Marek Behún wrote: > Use the LIBRESSL_VERSION_NUMBER macro to determine if building with > LibreSSL instead of OpenSSL. This is pretty straightforward, since > it is enough to add this check to existing #if macros. > > Signed-off-by: Marek Behun <kabel@blackhole.sk> > --- > libavformat/tls_openssl.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c > index 3d9768a..cf1a62e 100644 > --- a/libavformat/tls_openssl.c > +++ b/libavformat/tls_openssl.c > @@ -43,7 +43,7 @@ typedef struct TLSContext { > TLSShared tls_shared; > SSL_CTX *ctx; > SSL *ssl; > -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL && !defined(LIBRESSL_VERSION_NUMBER) I don't understand what this is trying to do. Does LibreSSL support the OpenSSL 1.1.0 API: If yes, why would the additional check be needed? If no, isn't this doing nothing because the first check would be false?
On Fri, 27 Jan 2017 18:41:09 +0000 Mark Thompson <sw@jkqxz.net> wrote: > On 27/01/17 17:31, Marek Behún wrote: > > Use the LIBRESSL_VERSION_NUMBER macro to determine if building with > > LibreSSL instead of OpenSSL. This is pretty straightforward, since > > it is enough to add this check to existing #if macros. > > > > Signed-off-by: Marek Behun <kabel@blackhole.sk> > > --- > > libavformat/tls_openssl.c | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c > > index 3d9768a..cf1a62e 100644 > > --- a/libavformat/tls_openssl.c > > +++ b/libavformat/tls_openssl.c > > @@ -43,7 +43,7 @@ typedef struct TLSContext { > > TLSShared tls_shared; > > SSL_CTX *ctx; > > SSL *ssl; > > -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > > +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > > && !defined(LIBRESSL_VERSION_NUMBER) > > I don't understand what this is trying to do. > > Does LibreSSL support the OpenSSL 1.1.0 API: > > If yes, why would the additional check be needed? > > If no, isn't this doing nothing because the first check would be > false? LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x2000000, thus OPENSSL_VERSION_NUMBER is always greater than 0x1010000, but LibreSSL does not support 1.1.0 API.
On 27/01/17 19:15, Marek Behun wrote: > On Fri, 27 Jan 2017 18:41:09 +0000 > Mark Thompson <sw@jkqxz.net> wrote: > >> On 27/01/17 17:31, Marek Behún wrote: >>> Use the LIBRESSL_VERSION_NUMBER macro to determine if building with >>> LibreSSL instead of OpenSSL. This is pretty straightforward, since >>> it is enough to add this check to existing #if macros. >>> >>> Signed-off-by: Marek Behun <kabel@blackhole.sk> >>> --- >>> libavformat/tls_openssl.c | 12 ++++++------ >>> 1 file changed, 6 insertions(+), 6 deletions(-) >>> >>> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c >>> index 3d9768a..cf1a62e 100644 >>> --- a/libavformat/tls_openssl.c >>> +++ b/libavformat/tls_openssl.c >>> @@ -43,7 +43,7 @@ typedef struct TLSContext { >>> TLSShared tls_shared; >>> SSL_CTX *ctx; >>> SSL *ssl; >>> -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL >>> +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL >>> && !defined(LIBRESSL_VERSION_NUMBER) >> >> I don't understand what this is trying to do. >> >> Does LibreSSL support the OpenSSL 1.1.0 API: >> >> If yes, why would the additional check be needed? >> >> If no, isn't this doing nothing because the first check would be >> false? > > LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x2000000, thus > OPENSSL_VERSION_NUMBER is always greater than 0x1010000, but LibreSSL > does not support 1.1.0 API. Er, right, so it just lies and leaves it to user programs to sort it out. How nice. Looking back, I can see this has been discussed before: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201960.html> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203998.html> That (beyond the disapprobation towards libressl for being naughty) looks like people would prefer the test to be in configure rather than copying the nontrivial #if condition everywhere? - Mark
On Fri, 27 Jan 2017 19:53:50 +0000 Mark Thompson <sw@jkqxz.net> wrote: > On 27/01/17 19:15, Marek Behun wrote: > > On Fri, 27 Jan 2017 18:41:09 +0000 > > Mark Thompson <sw@jkqxz.net> wrote: > > > >> On 27/01/17 17:31, Marek Behún wrote: > >>> Use the LIBRESSL_VERSION_NUMBER macro to determine if building with > >>> LibreSSL instead of OpenSSL. This is pretty straightforward, since > >>> it is enough to add this check to existing #if macros. > >>> > >>> Signed-off-by: Marek Behun <kabel@blackhole.sk> > >>> --- > >>> libavformat/tls_openssl.c | 12 ++++++------ > >>> 1 file changed, 6 insertions(+), 6 deletions(-) > >>> > >>> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c > >>> index 3d9768a..cf1a62e 100644 > >>> --- a/libavformat/tls_openssl.c > >>> +++ b/libavformat/tls_openssl.c > >>> @@ -43,7 +43,7 @@ typedef struct TLSContext { > >>> TLSShared tls_shared; > >>> SSL_CTX *ctx; > >>> SSL *ssl; > >>> -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > >>> +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > >>> && !defined(LIBRESSL_VERSION_NUMBER) > >> > >> I don't understand what this is trying to do. > >> > >> Does LibreSSL support the OpenSSL 1.1.0 API: > >> > >> If yes, why would the additional check be needed? > >> > >> If no, isn't this doing nothing because the first check would be > >> false? > > > > LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x2000000, thus > > OPENSSL_VERSION_NUMBER is always greater than 0x1010000, but LibreSSL > > does not support 1.1.0 API. > > Er, right, so it just lies and leaves it to user programs to sort it out. How nice. > > Looking back, I can see this has been discussed before: > <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201960.html> > <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203998.html> > > That (beyond the disapprobation towards libressl for being naughty) looks like people would prefer the test to be in configure rather than copying the nontrivial #if condition everywhere? Maybe LibreSSL should fix this upstream. They're doing an extreme disservice to everyone by breaking every single downstream program. I'd even go as far as saying we shouldn't bother with LibreSSL if trying to keep compatibility is going to be a mess this huge.
On 28/01/17 11:28, wm4 wrote: > On Fri, 27 Jan 2017 19:53:50 +0000 > Mark Thompson <sw@jkqxz.net> wrote: > >> On 27/01/17 19:15, Marek Behun wrote: >>> On Fri, 27 Jan 2017 18:41:09 +0000 >>> Mark Thompson <sw@jkqxz.net> wrote: >>> >>>> On 27/01/17 17:31, Marek Behún wrote: >>>>> Use the LIBRESSL_VERSION_NUMBER macro to determine if building with >>>>> LibreSSL instead of OpenSSL. This is pretty straightforward, since >>>>> it is enough to add this check to existing #if macros. >>>>> >>>>> Signed-off-by: Marek Behun <kabel@blackhole.sk> >>>>> --- >>>>> libavformat/tls_openssl.c | 12 ++++++------ >>>>> 1 file changed, 6 insertions(+), 6 deletions(-) >>>>> >>>>> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c >>>>> index 3d9768a..cf1a62e 100644 >>>>> --- a/libavformat/tls_openssl.c >>>>> +++ b/libavformat/tls_openssl.c >>>>> @@ -43,7 +43,7 @@ typedef struct TLSContext { >>>>> TLSShared tls_shared; >>>>> SSL_CTX *ctx; >>>>> SSL *ssl; >>>>> -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL >>>>> +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL >>>>> && !defined(LIBRESSL_VERSION_NUMBER) >>>> >>>> I don't understand what this is trying to do. >>>> >>>> Does LibreSSL support the OpenSSL 1.1.0 API: >>>> >>>> If yes, why would the additional check be needed? >>>> >>>> If no, isn't this doing nothing because the first check would be >>>> false? >>> >>> LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x2000000, thus >>> OPENSSL_VERSION_NUMBER is always greater than 0x1010000, but LibreSSL >>> does not support 1.1.0 API. >> >> Er, right, so it just lies and leaves it to user programs to sort it out. How nice. >> >> Looking back, I can see this has been discussed before: >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201960.html> >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203998.html> >> >> That (beyond the disapprobation towards libressl for being naughty) looks like people would prefer the test to be in configure rather than copying the nontrivial #if condition everywhere? > > Maybe LibreSSL should fix this upstream. > > They're doing an extreme disservice to everyone by breaking every > single downstream program. > > I'd even go as far as saying we shouldn't bother with LibreSSL if > trying to keep compatibility is going to be a mess this huge. If it becomes more inconvenient to do so, yes. (At that point probably just clone tls_openssl.c to tls_libressl.c and let them diverge if support is still wanted.) On the other hand, I think the now-proposed change (configure-detected) is positive even ignoring the existence of LibreSSL, since it moves a whole set of repeated version-conditional #ifs into one configure variable.
On Sat, 28 Jan 2017 13:01:54 +0000 Mark Thompson <sw@jkqxz.net> wrote: > On 28/01/17 11:28, wm4 wrote: > > On Fri, 27 Jan 2017 19:53:50 +0000 > > Mark Thompson <sw@jkqxz.net> wrote: > > > >> On 27/01/17 19:15, Marek Behun wrote: > >>> On Fri, 27 Jan 2017 18:41:09 +0000 > >>> Mark Thompson <sw@jkqxz.net> wrote: > >>> > >>>> On 27/01/17 17:31, Marek Behún wrote: > >>>>> Use the LIBRESSL_VERSION_NUMBER macro to determine if building with > >>>>> LibreSSL instead of OpenSSL. This is pretty straightforward, since > >>>>> it is enough to add this check to existing #if macros. > >>>>> > >>>>> Signed-off-by: Marek Behun <kabel@blackhole.sk> > >>>>> --- > >>>>> libavformat/tls_openssl.c | 12 ++++++------ > >>>>> 1 file changed, 6 insertions(+), 6 deletions(-) > >>>>> > >>>>> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c > >>>>> index 3d9768a..cf1a62e 100644 > >>>>> --- a/libavformat/tls_openssl.c > >>>>> +++ b/libavformat/tls_openssl.c > >>>>> @@ -43,7 +43,7 @@ typedef struct TLSContext { > >>>>> TLSShared tls_shared; > >>>>> SSL_CTX *ctx; > >>>>> SSL *ssl; > >>>>> -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > >>>>> +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > >>>>> && !defined(LIBRESSL_VERSION_NUMBER) > >>>> > >>>> I don't understand what this is trying to do. > >>>> > >>>> Does LibreSSL support the OpenSSL 1.1.0 API: > >>>> > >>>> If yes, why would the additional check be needed? > >>>> > >>>> If no, isn't this doing nothing because the first check would be > >>>> false? > >>> > >>> LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x2000000, thus > >>> OPENSSL_VERSION_NUMBER is always greater than 0x1010000, but LibreSSL > >>> does not support 1.1.0 API. > >> > >> Er, right, so it just lies and leaves it to user programs to sort it out. How nice. > >> > >> Looking back, I can see this has been discussed before: > >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201960.html> > >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203998.html> > >> > >> That (beyond the disapprobation towards libressl for being naughty) looks like people would prefer the test to be in configure rather than copying the nontrivial #if condition everywhere? > > > > Maybe LibreSSL should fix this upstream. > > > > They're doing an extreme disservice to everyone by breaking every > > single downstream program. > > > > I'd even go as far as saying we shouldn't bother with LibreSSL if > > trying to keep compatibility is going to be a mess this huge. > > If it becomes more inconvenient to do so, yes. > (At that point probably just clone tls_openssl.c to tls_libressl.c and > let them diverge if support is still wanted.) Well, I suspect LibreSSL will continue their "low quality" compatibility with OpenSSL, so it will remain a cat and mouse game. > On the other hand, I think the now-proposed change (configure-detected) is positive even ignoring the existence of LibreSSL, since it moves a whole set of repeated version-conditional #ifs into one configure variable. Yes, until next time another part of the API breaks. Anyway, just to make it clear: I don't mind the currently proposed patch.
On Sat, 28 Jan 2017 14:07:45 +0100 wm4 <nfxjfg@googlemail.com> wrote: > On Sat, 28 Jan 2017 13:01:54 +0000 > Mark Thompson <sw@jkqxz.net> wrote: > > > On 28/01/17 11:28, wm4 wrote: > > > On Fri, 27 Jan 2017 19:53:50 +0000 > > > Mark Thompson <sw@jkqxz.net> wrote: > > > > > >> On 27/01/17 19:15, Marek Behun wrote: > > >>> On Fri, 27 Jan 2017 18:41:09 +0000 > > >>> Mark Thompson <sw@jkqxz.net> wrote: > > >>> > > >>>> On 27/01/17 17:31, Marek Behún wrote: > > >>>>> Use the LIBRESSL_VERSION_NUMBER macro to determine if > > >>>>> building with LibreSSL instead of OpenSSL. This is pretty > > >>>>> straightforward, since it is enough to add this check to > > >>>>> existing #if macros. > > >>>>> > > >>>>> Signed-off-by: Marek Behun <kabel@blackhole.sk> > > >>>>> --- > > >>>>> libavformat/tls_openssl.c | 12 ++++++------ > > >>>>> 1 file changed, 6 insertions(+), 6 deletions(-) > > >>>>> > > >>>>> diff --git a/libavformat/tls_openssl.c > > >>>>> b/libavformat/tls_openssl.c index 3d9768a..cf1a62e 100644 > > >>>>> --- a/libavformat/tls_openssl.c > > >>>>> +++ b/libavformat/tls_openssl.c > > >>>>> @@ -43,7 +43,7 @@ typedef struct TLSContext { > > >>>>> TLSShared tls_shared; > > >>>>> SSL_CTX *ctx; > > >>>>> SSL *ssl; > > >>>>> -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > > >>>>> +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > > >>>>> && !defined(LIBRESSL_VERSION_NUMBER) > > >>>> > > >>>> I don't understand what this is trying to do. > > >>>> > > >>>> Does LibreSSL support the OpenSSL 1.1.0 API: > > >>>> > > >>>> If yes, why would the additional check be needed? > > >>>> > > >>>> If no, isn't this doing nothing because the first check would > > >>>> be false? > > >>> > > >>> LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x2000000, thus > > >>> OPENSSL_VERSION_NUMBER is always greater than 0x1010000, but > > >>> LibreSSL does not support 1.1.0 API. > > >> > > >> Er, right, so it just lies and leaves it to user programs to > > >> sort it out. How nice. > > >> > > >> Looking back, I can see this has been discussed before: > > >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201960.html> > > >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203998.html> > > >> > > >> That (beyond the disapprobation towards libressl for being > > >> naughty) looks like people would prefer the test to be in > > >> configure rather than copying the nontrivial #if condition > > >> everywhere? > > > > > > Maybe LibreSSL should fix this upstream. > > > > > > They're doing an extreme disservice to everyone by breaking every > > > single downstream program. > > > > > > I'd even go as far as saying we shouldn't bother with LibreSSL if > > > trying to keep compatibility is going to be a mess this huge. > > > > If it becomes more inconvenient to do so, yes. > > > (At that point probably just clone tls_openssl.c to tls_libressl.c > > and let them diverge if support is still wanted.) The support would be wanted, for sure. FreeBSD, OpenBSD and Gentoo want to support LibreSSL: - OpenBSD already removed openssl completely, since the security flaws of openssl are unacceptable to them. - FreeBSD states that "Currently there are no binary distributions for LibreSSL-in-base but this is to change with the release of FreeBSD 11." - Gentoo has a USE flag for libressl and Gentoo bug #561854, which tracks LibreSSL incompatibilities, has majority of dependencies solved. My guess is that the OpenBSD guys want the world to get rid of openssl completely (see for example http://opensslrampage.org/), and breaking API compatibility with openssl is their "strategy". Well, this strategy maybe is inconveniet for others, but having seen the code of openssl, I would rather inconveniet myself with porting to LibreSSL than use OpenSSL. Marek
On 29 January 2017 at 01:00, Marek Behun <kabel@blackhole.sk> wrote: > On Sat, 28 Jan 2017 14:07:45 +0100 > wm4 <nfxjfg@googlemail.com> wrote: > > > On Sat, 28 Jan 2017 13:01:54 +0000 > > Mark Thompson <sw@jkqxz.net> wrote: > > > > > On 28/01/17 11:28, wm4 wrote: > > > > On Fri, 27 Jan 2017 19:53:50 +0000 > > > > Mark Thompson <sw@jkqxz.net> wrote: > > > > > > > >> On 27/01/17 19:15, Marek Behun wrote: > > > >>> On Fri, 27 Jan 2017 18:41:09 +0000 > > > >>> Mark Thompson <sw@jkqxz.net> wrote: > > > >>> > > > >>>> On 27/01/17 17:31, Marek Behún wrote: > > > >>>>> Use the LIBRESSL_VERSION_NUMBER macro to determine if > > > >>>>> building with LibreSSL instead of OpenSSL. This is pretty > > > >>>>> straightforward, since it is enough to add this check to > > > >>>>> existing #if macros. > > > >>>>> > > > >>>>> Signed-off-by: Marek Behun <kabel@blackhole.sk> > > > >>>>> --- > > > >>>>> libavformat/tls_openssl.c | 12 ++++++------ > > > >>>>> 1 file changed, 6 insertions(+), 6 deletions(-) > > > >>>>> > > > >>>>> diff --git a/libavformat/tls_openssl.c > > > >>>>> b/libavformat/tls_openssl.c index 3d9768a..cf1a62e 100644 > > > >>>>> --- a/libavformat/tls_openssl.c > > > >>>>> +++ b/libavformat/tls_openssl.c > > > >>>>> @@ -43,7 +43,7 @@ typedef struct TLSContext { > > > >>>>> TLSShared tls_shared; > > > >>>>> SSL_CTX *ctx; > > > >>>>> SSL *ssl; > > > >>>>> -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > > > >>>>> +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > > > >>>>> && !defined(LIBRESSL_VERSION_NUMBER) > > > >>>> > > > >>>> I don't understand what this is trying to do. > > > >>>> > > > >>>> Does LibreSSL support the OpenSSL 1.1.0 API: > > > >>>> > > > >>>> If yes, why would the additional check be needed? > > > >>>> > > > >>>> If no, isn't this doing nothing because the first check would > > > >>>> be false? > > > >>> > > > >>> LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x2000000, thus > > > >>> OPENSSL_VERSION_NUMBER is always greater than 0x1010000, but > > > >>> LibreSSL does not support 1.1.0 API. > > > >> > > > >> Er, right, so it just lies and leaves it to user programs to > > > >> sort it out. How nice. > > > >> > > > >> Looking back, I can see this has been discussed before: > > > >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016- > October/201960.html> > > > >> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016- > December/203998.html> > > > >> > > > >> That (beyond the disapprobation towards libressl for being > > > >> naughty) looks like people would prefer the test to be in > > > >> configure rather than copying the nontrivial #if condition > > > >> everywhere? > > > > > > > > Maybe LibreSSL should fix this upstream. > > > > > > > > They're doing an extreme disservice to everyone by breaking every > > > > single downstream program. > > > > > > > > I'd even go as far as saying we shouldn't bother with LibreSSL if > > > > trying to keep compatibility is going to be a mess this huge. > > > > > > If it becomes more inconvenient to do so, yes. > > > > > (At that point probably just clone tls_openssl.c to tls_libressl.c > > > and let them diverge if support is still wanted.) > > The support would be wanted, for sure. FreeBSD, OpenBSD and Gentoo want > to support LibreSSL: > - OpenBSD already removed openssl completely, since the security flaws > of openssl are unacceptable to them. > - FreeBSD states that "Currently there are no binary distributions for > LibreSSL-in-base but this is to change with the release of FreeBSD > 11." > - Gentoo has a USE flag for libressl and Gentoo bug #561854, which > tracks LibreSSL incompatibilities, has majority of dependencies > solved. > > My guess is that the OpenBSD guys want the world to get rid of openssl > completely (see for example http://opensslrampage.org/), and breaking > API compatibility with openssl is their "strategy". Well, this strategy > maybe is inconveniet for others, but having seen the code of openssl, I > would rather inconveniet myself with porting to LibreSSL than use > OpenSSL. > Well perhaps making a tls_libressl implementation would be the better way to go as the APIs are only going to diverge further. So perhaps in order to support LibreSSL there should be a separate implementation using LibreSSLs independent libtls instead of the older openssl support interface. libtls is the recommended and primarily supported interface when using LibreSSL so that should be used going forward instead of further complication the opensll code.
On Sun, 29 Jan 2017 22:35:12 +1100 Matt Oliver <protogonoi@gmail.com> wrote: > Well perhaps making a tls_libressl implementation would be the better > way to go as the APIs are only going to diverge further. So perhaps > in order to support LibreSSL there should be a separate > implementation using LibreSSLs independent libtls instead of the > older openssl support interface. libtls is the recommended and > primarily supported interface when using LibreSSL so that should be > used going forward instead of further complication the opensll code. Yes, that would be the optimal solution, I think. But still, even if not considering LibreSSL, the currently proposed patch is probably a better way to check for BIO_meth_* calls in OpenSSL. That it also works with LibreSSL can be considered as a bonus. Maybe the commit message should be changed.
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c index 3d9768a..cf1a62e 100644 --- a/libavformat/tls_openssl.c +++ b/libavformat/tls_openssl.c @@ -43,7 +43,7 @@ typedef struct TLSContext { TLSShared tls_shared; SSL_CTX *ctx; SSL *ssl; -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL && !defined(LIBRESSL_VERSION_NUMBER) BIO_METHOD* url_bio_method; #endif } TLSContext; @@ -68,7 +68,7 @@ static unsigned long openssl_thread_id(void) static int url_bio_create(BIO *b) { -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL && !defined(LIBRESSL_VERSION_NUMBER) BIO_set_init(b, 1); BIO_set_data(b, NULL); BIO_set_flags(b, 0); @@ -85,7 +85,7 @@ static int url_bio_destroy(BIO *b) return 1; } -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL && !defined(LIBRESSL_VERSION_NUMBER) #define GET_BIO_DATA(x) BIO_get_data(x); #else #define GET_BIO_DATA(x) (x)->ptr; @@ -133,7 +133,7 @@ static int url_bio_bputs(BIO *b, const char *str) return url_bio_bwrite(b, str, strlen(str)); } -#if OPENSSL_VERSION_NUMBER < 0x1010000fL +#if OPENSSL_VERSION_NUMBER < 0x1010000fL || defined(LIBRESSL_VERSION_NUMBER) static BIO_METHOD url_bio_method = { .type = BIO_TYPE_SOURCE_SINK, .name = "urlprotocol bio", @@ -212,7 +212,7 @@ static int tls_close(URLContext *h) SSL_CTX_free(c->ctx); if (c->tls_shared.tcp) ffurl_close(c->tls_shared.tcp); -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL && !defined(LIBRESSL_VERSION_NUMBER) if (c->url_bio_method) BIO_meth_free(c->url_bio_method); #endif @@ -270,7 +270,7 @@ static int tls_open(URLContext *h, const char *uri, int flags, AVDictionary **op ret = AVERROR(EIO); goto fail; } -#if OPENSSL_VERSION_NUMBER >= 0x1010000fL +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL && !defined(LIBRESSL_VERSION_NUMBER) p->url_bio_method = BIO_meth_new(BIO_TYPE_SOURCE_SINK, "urlprotocol bio"); BIO_meth_set_write(p->url_bio_method, url_bio_bwrite); BIO_meth_set_read(p->url_bio_method, url_bio_bread);
Use the LIBRESSL_VERSION_NUMBER macro to determine if building with LibreSSL instead of OpenSSL. This is pretty straightforward, since it is enough to add this check to existing #if macros. Signed-off-by: Marek Behun <kabel@blackhole.sk> --- libavformat/tls_openssl.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)