On Mon, Mar 08, 2010 at 03:50:37PM -0800, Steve Langasek wrote: > On Tue, Mar 09, 2010 at 10:34:37AM +1100, Brian May wrote: > > Unfortunately, gcrypt is used by gnutls, which is used in ldap, which > > is frequently used in PAM and NSS. So this is an issue. There might be > > other NSS and PAM modules that use it too. > > > 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? > > There is no "going back" to openssl. OpenSSL is license-incompatible with > many LDAP-using applications in Debian, and I don't see any way that we can > justify distributing an LDAP library that *doesn't* support TLS in this day > and age. > > If gcrypt is broken, then we should fix gcrypt. The issue here is that upstream don't appear to want to fix it, because the change in behaviour could break backward compatibility and potentially introduce security exploits into programs relying on this side-effect of gcrypt. Any change would require the use of a new interface, leaving all existing code still affected. It might be worth looking at the rdepends to see how many are setuid, since these are the only ones affected. For those that are, they just need a setuid() call adding to drop root privs. At this point, the privilege-dropping code can just be removed from libgcrypt lock_pool(). Given the PAM and NSS breakage, I'd say this was an RC bug in gcrypt. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Description: Digital signature