[Date Prev][Date Next] [Chronological] [Thread] [Top]

Accursed LDAP+SSL Breakage When Using libgcrypt


I abandoned any efforts to get anyone to hack the broken libgcrypt11
 so that it would stop dropping setuid permissions.  This was motivated
 largely by the fact that upstream GnuTLS started releasing versions
 that were intended to stop using libcrypt as the crypto back-end along
 with support for multiple crypto back-ends.  The preferred crypto library
 for GnuTLS is nettle now.  This change requires a minimum of
 GnuTLS 2.11.x and Ubuntu 12.04 is using GnuTLS 2.12.x.

There were miscellaneous announcements made about this change:

Andreas Metzler
{{ GnuTLS upstream has added support for different crypto backends in
2.11.x and has chosen nettle as prefered [sic] backend (2.10.x is using
libgcrypt). }}

It works for me, when I configure GnuTLS on Ubuntu 12.04 to use
nettle the painful regression goes away and I can use setuid
binaries from an LDAP account configured to access an LDAP
server via SSL.

To test on Ubuntu 12.04 or Debian Testing or Unstable simply:

apt-get build-dep libgnutls26

apt-get source gnutls26
to fetch the source for gnutls26-2.12.14 (or 2.12.16-1 on Debian)

then chop out
from the debian/rules file
and rebuild gnutls26
debuild -i -uc -us -b
and install the resulting .deb files.

Much to my chagrin, upstream Debian still configures GnuTLS to use
the horribly defective and rejected-by-upstream libgcrypt11 instead
of the preferred-by-upstream nettle despite both Debian Testing
and Debian Unstable having GnuTLS 2.12.16-1

$ grep with-libgcrypt sid/gnutls26-2.12.16/debian/rules 
    --cache-file=$(CURDIR)/config.cache --with-libgcrypt \

So I opened two bug reports:



Hope that helps.