Re: libgcrypt brain dead?
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
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