GitLab

If a certificate does not validate, the user will be given the option
to accept it manually. GnuTLS will then store the certificate in its
known hosts database.

This will be used for fine-grained GnuTLS stored public keys,
i.e. SSH-like authentication on first use.

The TLS plugin now supports reusing the same set of credentials for
multiple sessions also on the client side.

Support for custom certificates will be better addressed with the
stored public key support in the GnuTLS library (in latter commit).

Support for private keys on client side was practically useless.

GnuTLS system trust supports more systems, and supports Linux and
Windows better, than the old custom code.

This enables the use of vlc_custom_create() and, later, sharing more
code between server and client sides.

There are no (other) reasons for the GnuTLS plugin to link against
libgcrypt. Since nettle has been the default back-end for GnuTLS for
ages, this old code has become more harmful than good.

Besides, this code was not sufficient to really address the thread
safety issues in libgcrypt (since it is also used via other paths).

The configuration system cannot store both a static list and a dynamic
one (and AFAIK, it never could). It only makes to use either a static
list or a callback.

Signed-off-by: Rafaël Carré <funman@videolan.org>

Newer GnuTLS versions do it internally and in a more correct fashion.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This fixes some problems when the system or VLC play evil tricks with
the preprocessor. (Only files including sys/stat.h are concerned with
this commit. I did not fix all files.)

This was lame as we did not ever call db_check.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Ref #3682 and #3666
Now, we have
[022d6ffc] main tls client debug: TLS client session initialized
instead of
[004e6ffc] gnutls tls client error: Certificate could not be verified

However, this still doesn't work fine, since we got a:
"access_http acccess error: failed to read answer"
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>