Howard Chu <h...@highlandsun.com> writes: >> 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.
I don't see that, I believe the root cause is that applications are not initializing libgcrypting properly. Read the libgcrypt manual, it is explained there. We can discuss changing the design of libgcrypt works, but unless that has happened, the problem remains with the applications, and, fortunately, the problem can easily be fixed by the applications initializing Libgcrypt as documented. We could also discuss changing GnuTLS' use of Libgcrypt, but that also does not change the fundamental problem. > 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 > App writers using gnutls should not need to know that libgcrypt is > under the covers and needs special handling. The Libgcrypt designers appears to have believed otherwise, and given how broken the applications appear to be in this area decision (setuid programs doing LDAP+TLS? Sigh) it seems that was useful because we are now aware of these sub-optimal security practices. Working on fixing this to use a better mechanism (userv was mentioned) would be useful regardless of what is done (or not) in GnuTLS/Libgcrypt. The crypto parts of OpenSSL have a similar issue: they need mutexes provided by the application. Many libraries using OpenSSL doesn't provide an interface to provide these mutexes, but depend on the application initializing OpenSSL themselves. > (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. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
