See comment #72 of this launchpad bug report for a detailed description
of why libgcrypts behavior causes the problem in libldap.
https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/
https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72
Note that the root cause here is that gnutls depends on libgcrypt but doesn't
fully encapsulate it. None of the gnutls docs mention that any special
initialization function needs to be called when using it in a threaded
application. App writers using gnutls should not need to know that libgcrypt
is under the covers and needs special handling. (Indeed, as illustrated in
this bug report, apps generally won't and can't know anything about the
underlying libraries.) 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.
--
-- 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
