Bug#566351: libgcrypt problem

[Howard Chu]

Simon Josefsson wrote:
> Howard Chu<hyc at highlandsun.com>  writes:
>> None of the gnutls docs mention that any special initialization
>> function needs to be called when using it in a threaded application.
>
> You must have missed this section:
>
> http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html

Not at all. OpenLDAP libldap_r does precisely these two steps, as documented 
in your link:
            gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
            gnutls_global_init();

But that is completely useless, due to the behavior inside libgcrypt and 
gnutls which I already explained in here

https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72

>> (Indeed, as illustrated in this bug report, apps generally won't and
>> can't know anything about the underlying libraries.)
>
> That is a problem indeed.
>
>> So aside from deciding what fix if any is appropriate for libgcrypt's
>> secmem implementation, the larger issue remains of how to make
>> libgcrypt safe for use when it's nested under other libraries like
>> gnutls. Saying "applications are responsible for correctly
>> initializing libgcrypt" is a non-starter. libgcrypt needs to have that
>> requirement removed, and gnutls needs to be more comprehensive and
>> explicit in the steps it takes to initialize libgcrypt, so that gnutls
>> callers are completely shielded from the lower API layers.
>
> Right, I think things can be improved here.  However sometimes it is not
> possible to shield applications from lower API layers: compare threads.
> You can't have a multi-threaded application access the entropy functions
> in any reliable manner with Libgcrypt or OpenSSL.  The application needs
> to provide the libraries with mutexes for the thread library it is
> using, so the libraries can protect these accesses properly.

Yes, it's a thorny issue. There are only two good solutions I'm aware of:
  - compile in a default set of thread callbacks, whose actual implementations 
point to the "native" thread library using weak external references. If the 
thread library is present, all the API references will resolve, otherwise they 
remain as NULL pointers and can be ignored.
  - ask for help from glibc. libc could provide a vector of function pointers 
for pthread support; this would be init'd as no-ops by default, and 
transparently replaced with the real thing when libpthreads is loaded into the 
process' address space.

Other libraries which need to be thread-agnostic then won't need any special 
initialization at all, nor would there be any race conditions any more.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/