On Tue, 09 Mar 2010, Brian May wrote: > A number of packages, such as openldap have been changed to support > gnutls, instead of openssl, to avoid licensing issues in openssl. > > However, it appears that gnutls uses libgcrypt, and libgcrypt has > several serious design issues. > > 1. libgcrypt doesn't cleanup properly on dlclose, and apparently won't > fix the problem:
... > 2. libgcrypt drops root privileges if called setuid on the assumption > the only reason the program is setuid root is so it can lock memory. Requirements for a core library that is going to be linked by other core libraries, and used in NSS modules: 1. All public symbols MUST be versioned; 2. Must be thread-safe, and fully reentrant both at the function and at the _library_ level; 3. The entire library must work using contexts passed at every function call that needs one; 4. Must not change any global attributes of the process or of any other libraries it uses; 5. Must not link to any library that doesn't implement the above; This is _hard_. I am sure I forgot some... > What is the solution? Should we go back to using openssl, at least > with libraries such as openldap that are commonly used in pam and nss > modules? We'd have to move gnutls to some proper crypto library that behaves like a proper library should, to really fix it. And that does assume gnutls itself does it properly... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100320035031.gd16...@khazad-dum.debian.net
