Hi,
This is a patchset I wrote some time ago but haven't submitted
until now.
This implements a protocol 'tls', which works just as 'tcp',
but with TLS/SSL encrypted. This is implemented using either
OpenSSL (which perhaps is the most widely used TLS/SSL library)
and GnuTLS (which has the benefit of being LGPLv2).
(However, since GnuTLS 3.0, the license has been changed to
LGPLv3 - the configure check detects this and requires
--enable-version3 if using that version. But older versions
are still available, and I'm not aware of any other mature
LGPLv2 lib.)
Basic background info around these libraries: OpenSSL is
composed of two libraries, libssl and libcrypto. GnuTLS
only implements the part corresponding to libssl in itself,
and earlier used gcrypt as crypto backend. Since GnuTLS 2.12,
it uses nettle instead of gcrypt as default backend (keeping
gcrypt as an option).
There's one big unsolved issue around this patchset, that
I want input on how to solve in the best way:
All these libraries require some kind of global init.
In addition to a normal global library init function that
needs to be called, some of the underlying crypto libraries
require threading callback functions to be set up, in order
for the crypto libraries to be thread safe in practice (just
like av_lockmgr_register in libavcodec).
For the thread safety callbacks, in theory, the calling app
could be using any threading package, and thus has to be
supplied and set up by the application that actually create
the threads. Therefore, they aren't normally set up
automatically by default.
libcurl, which can link to either of these SSL libraries (and
a number of others, too), doesn't set up them either, but
requires the calling application to set it up, otherwise libcurl
won't be thread safe. This, on the other hand, kind of violates
layering, requiring the calling application not only to know
that it uses libcurl, but also know whether libcurl uses
OpenSSL or GnuTLS, and whether GnuTLS uses gcrypt or nettle.
nettle doesn't require any threading callbacks, while both
gcrypt and libcrypto require them. Since GnuTLS 2.12,
gnutls_global_init() sets up default threading callbacks on
pthread and win32, to transition to avoiding this part of
the issue.
For libavformat's part, there's a tradeoff between simplicity
for unknowing callers and flexibility in weird cases. If
we don't set up callbacks, a currently correctly threaded
libavformat user might suddenly start failing if upgrading
to a version supporting https, if given such urls. On the
other hand, if libavformat sets up the callbacks, it might
overwrite some existing custom callbacks set up by the
application.
The last question is where we should do this global init of
libraries we depend on. As far as I can see, it can happen
at three different places:
- Some global libavformat init function. AFAIK, there is no
such suitable function yet - there's av_register_all, but
it isn't mandatory for users yet. Making some function
mandatory would require a major bump I guess.
- ff_network_init - which would be called automatically when
needed. The downside is that we'd be initializing
(and deinitializing) the SSL library a lot for each network
connection that libavformat does, regardless of whether it's
a SSL connection or something completely different.
- Within the protocol handler - avoiding unnecessary
initialization if it is used very seldom, but doing a lot of
extra work if doing a lot of https requests.
The latter two has the problem of happening "at runtime", where
e.g. setting up threading callbacks could interfer with ongoing
SSL library usage in other application threads that use the same
SSL library directly. (That is, the application can choose to
call the global libavformat init at a time before any else
work has been started, but it doesn't know exactly when
libavformat initializes the SSL library if it is done implicitly
at runtime.)
Martin Storsjö (6):
avcodec: Allow locking and unlocking an avformat specific mutex
configure: Allow linking to openssl
configure: Allow linking to the gnutls library
Add the tls protocol, using OpenSSL or gnutls
Add the https protocol, using tls instead of tcp as underlying
protocol
cmdutils: Rename read_file to ff_read_file
Changelog | 1 +
avconv.c | 2 +-
cmdutils.c | 2 +-
cmdutils.h | 2 +-
configure | 14 ++
ffmpeg.c | 2 +-
libavcodec/internal.h | 3 +
libavcodec/utils.c | 23 ++++
libavcodec/version.h | 2 +-
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/http.c | 29 ++++-
libavformat/tls.c | 330 ++++++++++++++++++++++++++++++++++++++++++++++
libavformat/version.h | 2 +-
14 files changed, 406 insertions(+), 10 deletions(-)
create mode 100644 libavformat/tls.c
--
1.7.3.1
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
