On Sat, 28 Jan 2017 14:07:45 +0100
wm4 <nfx...@googlemail.com> wrote:
> On Sat, 28 Jan 2017 13:01:54 +0000
> Mark Thompson <s...@jkqxz.net> wrote:
>
> > On 28/01/17 11:28, wm4 wrote:
> > > On Fri, 27 Jan 2017 19:53:50 +0000
> > > Mark Thompson <s...@jkqxz.net> wrote:
> > >
> > >> On 27/01/17 19:15, Marek Behun wrote:
> > >>> On Fri, 27 Jan 2017 18:41:09 +0000
> > >>> Mark Thompson <s...@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 <ka...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
