[libvirt] [PATCH 0/1] RFC Fix problems with TLS connections & threading

[Daniel P. Berrange]

Even though we are not using gcrypt directly in any libvirt code,
it turns out that we are responsible for initializing its thread
support, since its used by gnutls. This really sucks in terms of
library API encapsulation. It is also a little annoying if libvirt
is used within an app that already uses gnutls/gcrypt, because
there is no checking in gcrypt to see if threading ops are already
set, so our call would override any pre-existing initialization,
and an apps own call would override us.

The only other option I see is to punt on the whole problem and
declare apps are responsible for initializing gcrypt, but then
this sucks too because it means apps have to presume we're built
with gnutls, and not nss - not that we support nss currently.

This bug only really impacts the libvirt client if using multiple
virConnectPtr objects from separate threads with a TLS based URI.

The server isn't impacted because all TLS I/O is done from the
single I/O thread, and not any of the RPC workers.

Daniel P. Berrange (1):
  Initialize gcrypt threading

 src/remote_internal.c |   43 +++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 43 insertions(+), 0 deletions(-)