[Date Prev][Date Next]
Re: commit: ldap/libraries/libldap gnutls.c getdn.c tls.c
- To: OpenLDAP Commit <email@example.com>
- Subject: Re: commit: ldap/libraries/libldap gnutls.c getdn.c tls.c
- From: Howard Chu <firstname.lastname@example.org>
- Date: Fri, 23 Mar 2007 16:11:03 -0700
- In-reply-to: <200703232247.l2NMl8tY032683@cantor.openldap.org>
- References: <200703232247.l2NMl8tY032683@cantor.openldap.org>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070319 SeaMonkey/1.5a
Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
getdn.c 1.136 -> 1.137
tls.c 1.146 -> 1.147
gnutls.c NONE -> 1.1
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
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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/