GNOME Bugzilla – Bug 734858
GnuTLS /gcrypt code needs an update
Last modified: 2015-02-06 12:46:04 UTC
Hello, gtk-vnc's usage of gnutls requires a update. GnuTLS >> 2.12 does not use gcrypt as crypto backend anymore but uses nettle instead. 1. ./configure.ac assumes that gnutls requires gcrypt and that gnutls presence implies that gcrypt is available. 2. gtk-vnc uses gcry_control(GCRYCTL_SET_THREAD_CBS, ...). It should be reviewed if this is still the correct thing to do, considering this change in gnutls: ------------------------------ NEWS in gnutls 2.12 ** libgnutls: Added gnutls_global_set_mutex() to allow setting alternative locking procedures. By default the system available locking is used. In *NIX pthreads are used and in windows the critical section API. This follows a different approach than the previous versions that depended on libgcrypt initialization. The locks are now set by default in systems that support it. Programs that used gcry_control() to set thread locks should insert it into a block of #if GNUTLS_VERSION_NUMBER <= 0x020b00 gcry_control(...) #endif ------------------------------ 3. I am not sure it is feasible but if it is possible gtk-vnc should consider switching to GnuTLS' crypto API instead of gcrypt. - This would reduce external dependencies. Thanks for considering, cu Andreas
For added fun, with gcrypt >= 1.6.0 you must never initialize threading at all. I'd done some hairy version checks on gnutls & gcrypt, as well as checking the gnutls backend, to figure out when we must initialize gcrypt threading. commit 61cf2ff379edf3daeec135a68ff54bf8f3767cc1 Author: Daniel P. Berrange <berrange@redhat.com> Date: Fri Feb 6 12:43:01 2015 +0000 Fix initialization of gcrypt threading dependant on gnutls For GNUTLS 2.12, if it uses gcrypt, we must not initialize gcrypt threading ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=734858 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Getting rid of direct use of gcrypt is desirable, but not entirely trivial todo.