Bug#566351: libgcrypt problem
hyc at highlandsun.com
Fri Apr 30 08:38:53 UTC 2010
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:
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);
But that is completely useless, due to the behavior inside libgcrypt and
gnutls which I already explained in here
>> (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/
More information about the Pkg-gnutls-maint