Re: memory leaks

[Julio Sanchez Fernandez <j_sanchez@stl.es>]

Stig Venaas <Stig@OpenLDAP.org> writes:

> One other thing I noticed, is that certificateExactConvert(),
> certificateExactMatch() and certificateExactIndexer() don't check for
> NULL return from asn1_integer2str(), while certificateExactMatch() does.
> I haven't checked the code that carefully, not sure if it need to be done
> or not.

Probably should, I will have to look more closely at it.

Please notice that I wrote that part without having read the ID
recently and I got wrong the assertion syntax, the DN part of it has
to be in double quotes, and a double quote in the value is represented
by doubling, so more work will be needed there.  Ugly, but that is
what the ID says (and makes a little bit more sense when one reads
about the flexible certificate match).

Now that I am at it, I have to questions.

First, do we agree that the convert callback is used to get an
assertion value from a full value, that is, a value in the matching
rule definition syntax from a value in attribute definition syntax?
It was left unused and the prototype seemed right, but maybe was
planned for something else...

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?

Julio