On Mon, 25 May 2015, Luca Barbato wrote:
On 22/05/15 21:28, Martin Storsjö wrote:
Well, if you see gnutls/openssl only as libs that are used for
implementing the tls:// protocol, sure, but if you see them as generic
external libs that may have more or less overlapping tasks, it's not as
straightforward. (They are used for other things than that, but they're
exchangeable there as well.) See my reply to wm4's patch 1/2 for a
suggestion on how this can be handled differently, allowing both of them
to be enabled, but only building one out of N different tls protocol
implementations.
I'd rather not have mixes and matches with huge overlapping libraries.
Well, the fact that they are "huge" should only matter when you're
statically linking them, no?
Having support for more tls providers is nice since the rule 0 of
security is to not trust single implementations (even more if they are
made of dubious, pointlessly hard to read, code).
Which would be the advantage of having both gnutls and openssl (and nss,
and polar and ...) enabled at the same time?
The same as having e.g. the built-in rtmp and librtmp support at the same
time - allowing using either of them at runtime, if a particular user is
picky. (And in practice, simplify comparing the two.)
Anyway, with the way of structuring the code as I suggested to wm4 in the
end (which he also agreed is nice), the codepaths for the two (or more)
implementations shouldn't disturb each other.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
