[Date Prev][Date Next]
Re: memory leaks
- To: Julio Sanchez Fernandez <firstname.lastname@example.org>
- Subject: Re: memory leaks
- From: Pierangelo Masarati <email@example.com>
- Date: Wed, 05 Dec 2001 10:31:52 +0100
- Cc: openldap-devel@OpenLDAP.org, "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Organization: Dipartimento di Ingegneria Aerospaziale
- References: <Stig Venaas's message of "Tue, 6 Nov 2001 22:47:45 +0100"> <Pine.GSO.4.33Lfirstname.lastname@example.org> <Pine.GSO.4.33Lemail@example.com> <20011106224745.A23464@itea.ntnu.no> <firstname.lastname@example.org>
"Kurt D. Zeilenga" wrote:
> >Second, we have to many routines to mangle DNs. In this case I opted
> >by asking OpenSSL to give me a value in rfc2253 format, but older
> >OpenSSL versions do not support it. And then I don't trust it to
> >produce good results and I renormalize it...
> >Other parts of the OpenLDAP call X509_NAME_oneline that returns the DN
> >in the peculiar format of OpenSSL and then uses ldap_dcedn2dn to parse
> >that string and convert it to rfc2253. That seems fragile and, IIRC,
> >the oneline format was being kept for compatibility and was considered
> >broken as far as escaping goes, so parsing it may be impossible.
> >Should we parse the X509_NAME ourselves and build an rfc2253 value in
> >one go in a predictable, normalized, way?
> Well, prefer dealing with the BER/DER or 2253 strings. I would
> think it better to have our own BER/DER -> LDAPDN (see ando's
> work) -> 2253 mechanism. We'll need it for doing component
> matching anyways.
The best way would be to put together a LDAPDN structure directly
from the X509_NAME and then convert it in the format we prefer.
This is very easy if we can trust directly accessing the members
of X509_NAME. I'm not familiar with openssl internals, so I don't
know if this is feasible/reliable, though.
I see from openssl headers that the X509_NAME basically is a
stack of X509_NAME_ENTRY, each of which on turn is made of a
ASN1_OBJECT (the attr, I suppose) and a ASN1_STRING (the value).
If you can access the attrs and the values, all you need to do is
for each rdn
for each ava
ava = ldapava_new(attr, value)
This may become an utility (say ldap_X509NAME2dn); then
your function would be
dn = ldap_X509NAME2dn(name)
dnstr = ldap_dn2str(dn)
Finally, both ldap_pvt_tls_get_peer and ldap_pvt_tls_get_peer_dn
can be rewritten in terms of your function (ldap_X509dn2str ?),
since ldap_dn2str can handle DCE-like dn representation as well.
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano |
via La Masa 34, 20156 Milano, Italy |