[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: memory leaks
- To: Julio Sanchez Fernandez <j_sanchez@stl.es>
- Subject: Re: memory leaks
- From: Pierangelo Masarati <masarati@aero.polimi.it>
- 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.33L-022.0111051714530.20436-100000@nil.andrew.cmu.edu> <Pine.GSO.4.33L-022.0111061307270.3465-100000@nil.andrew.cmu.edu> <20011106224745.A23464@itea.ntnu.no> <5.1.0.14.0.20011108111257.01792e40@127.0.0.1>
"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)
ldapava_append_to_rdn(rdn, ava)
end
ldapava_append_to_dn(dn, rdn)
end
This may become an utility (say ldap_X509NAME2dn); then
your function would be
dn = ldap_X509NAME2dn(name)
dnstr = ldap_dn2str(dn)
ldapava_free_dn(dn)
return ber_bvstr(dnstr)
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.
Pierangelo.
--
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano |
mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy |
http://www.aero.polimi.it/~masarati