[FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[wm4]

On Mon, 23 Apr 2018 21:09:09 +0200
Thomas Volkert <silvo at gmx.net> wrote:

> On 23.04.2018 14:08, Rostislav Pehlivanov wrote:
> > On 23 April 2018 at 10:27, Thomas Volkert <silvo at gmx.net> wrote:
> >  
> >> On 22.04.2018 20:03, Carl Eugen Hoyos wrote:  
> >>> 2018-04-22 20:00 GMT+02:00, Nicolas George <george at nsup.org>:  
> >>>> Carl Eugen Hoyos (2018-04-22):  
> >>>>> How do you detect that this is not the "current version" of mbed?  
> >>>> Is it really our responsibility?  
> >>> We try to always do it and I believe that allowing LGPL makes
> >>> more sense and less headache: Since we do the checks so
> >>> rigorously it makes sense to assume we did it as correctly
> >>> for this case.
> >>>
> >>> I don't understand why we don't go the easy way that clearly
> >>> has advantages instead for the complicated way (with at
> >>> least some disadvantages).  
> >> Okay. I looked over their web page and the Debian packages again.
> >> The web page of mbedTLS declares Apache license as the "primary open
> >> source license".
> >>
> >> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if
> >> their are no further objections.
> >>
> >> Best regards,
> >> Thomas.
> >> _______________________________________________
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel at ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>  
> > I'd like some memory usage and performance comparisons to gnutls and  
> 
> The mbedTLS library uses less than half of the disc space compared to
> OpenSSL in this context.
> I don't have exact figures for memory consumption for different
> scenarios right now.
> 
> 
> > openssl before you push. This is the 6th (!!) TLS library we'd be
> > supporting.  
> 
> Two of the existing ones are OS specific.
> 
> In general, I see mbedTLS as an enrichment for FFmpeg. MbedTLS seems to
> be a promising alternative to OpenSSL and other TLS implementations in
> the context of embedded systems: the disk footprint is smaller out of
> the box, the memory footprint is smaller, the library is intentionally
> modular so that these can be reduced further at need
> (https://tls.mbed.org/tiny-ssl-library,
> https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint).
> 
> Additionally, in the planned context the mbedTLS library is already used
> for signaling out-of-band control messages between network peers. And it
> is planned to do some more tuning to the overall setup to get an even
> smaller version of mbedTLS on the target device.

To be honest that's not really convincing. How does it compare with
e.g. libtls?

In my opinion it's probably not wrong to give another TLS lib a try,
but:
1. It was kind of too early. You should at least have given us some
   time to respond.
2. Having many TLS wrappers is actually not a good thing because it
   will confuse users about which one to pick, and the wrappers will
   all have subtly different behavior that can become a problem for
   ffmpeg and libav* users.
3. It's hard to remove redundant things even after it has turned out
   that they were not that useful. (See e.g. how much effort it was to
   remove some of the virtually useless codec lib wrappers.)
But it's just my opinion that having fewer well maintained choices is
better than many with maintenance deficits.