Simon Josefsson wrote:
Howard Chu<h...@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/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
