[FFmpeg-devel] [PATCH]lavf/tls_openssl: Fix compilation with current libressl

Timo Rothenpieler timo at rothenpieler.org
Tue Nov 7 15:43:35 EET 2017


Am 07.11.2017 um 14:37 schrieb James Almer:
> On 11/7/2017 10:28 AM, Timo Rothenpieler wrote:
>>> I would very much rather have a way to get libressl to compile with
>>> tls_openssl.c, or just reject it altogether, than adding a duplicate
>>> module just for a fork that pretends to be compatible with a version of
>>> openssl but not providing the required API for it.
>>>
>>> I refuse to give special treatment to such a sloppy fork, especially
>>> when adding it would increase the complexity in configure (As only one
>>> tls module can be compiled per build).
>>> An "if not defined libressl" for every openssl >= 1.1 check is simpler
>>> and easier to maintain than a whole separate duplicate module.
>>
>>  From how I understand it, libtls is an entirely new API, so it would not
>> be a duplicate of the openssl backend.
> 
> Then how is Carl's patch supposed to work? Unless you mean new API on
> top of the inherited openssl 1.0 API. If that's the case and such new
> libressl specific API is worth using then a separate module could be
> considered (Or just some more ifdeffery in tls_openssl.c, much like we
> do for openssl 1.1), but if it works as is then as i said I want to
> avoid new TLS modules as much as possible.

LibreSSL offers an older version of the openssl API in libssl, and at 
the same time also a new somewhat cleaner one in libtls, which right now 
is just a wrapper, but who knows if it becomes the new default at some 
point.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171107/60874f06/attachment.bin>


More information about the ffmpeg-devel mailing list