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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
