hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
Modified Files: getdn.c 1.136 -> 1.137 tls.c 1.146 -> 1.147 Added Files: gnutls.c NONE -> 1.1
Log Message: Preliminary GNUtls support. gnutls.c will merge back into tls.c later.
The basic functionality is all working; if you replace tls.c with gnutls.c in the Makefile everything builds and runs. I decided to move the ldap_X509dn2bv() function into tls.c for now, since there's a different version for GNUtls. (I have not added gnutls.c to the Makefile, you can set it manually if you feel like testing this.)
The GNUtls version parses the DER certificate directly, using liblber. I think this may be the best way to go moving forward. I intend to remove the OpenSSL-specific DN parser in favor of this approach. This also means we can replace the OpenSSL-dependent code in slapd/schema_init.c for the certificate validator and normalizer with generic liblber stuff.
If any 3rd party code is using ldap_X509dn2bv() they're going to break. I suppose we could keep the old API around and use a new function name instead...
There's still a few missing pieces in the GNUtls support: I haven't tested any Diffie-Hellman exchanges yet. There is no support for session caching yet. GNUtls needs to read CRLs from a file, you can't just point it at a directory - so we need a config directive for this. (this also means that the TLSCACertificatePath directive doesn't work) GNUtls doesn't provide any API for parsing cipher suites/algorithm names. At present I have no idea how to make these end-user configurable, will probably have to write a patch for GNUtls. There's no API equivalent to the RandFile option; I have no idea how to seed GNUtls's PRNG. Since most platforms just use /dev/urandom this isn't a big deal. Certificate verification isn't present yet.
Wondering if we should silently accept the no-op directives or error out on them (TLSCACertificatePath, TLSRandFile). Just ignoring them for now.