Re: OpenLDAP 2.4.7 Bug?

["Allan E. Johannesen" <aej@WPI.EDU>]

>>>>> "ldapsoft" == Philip Guenther <guenther+ldapsoft@sendmail.com> writes:

ldapsoft> I guess Allan needs to go ahead and change the program that's
ldapsoft> generating these searches to explicitly test for empty parts and
ldapsoft> suppress them when building the filter.  (He should probably also
ldapsoft> check that it's doing RFC 2254 encoding of the values that it's
ldapsoft> inserting in the filters while he's at it.  It's no good to catch an
ldapsoft> empty first-name field if the user can ask for a first-name of "*"
ldapsoft> and generate "(cn=***lastname*)".  Generating filters isn't as
ldapsoft> trivial as one might wish.)

Yes, I put in a check for empty searches, but you've pointed out that the data
might contain other characters which might break the search.  The problem arose
when processing

last-name, first-name

where it was written:

last-name,

Had the person left off the comma, none of this brouhaha would have come to
light.  The simple program assumed that if there was a comma, something must be
after it.  If the person wrote:

last-name, *

then it's bound for failure again despite my recent patch.  Clearly, I need to
make it more robust.  It had been running for 5+ years without this trouble
appearing.

Actually, I don't care much about a search failing, but the search failed so
profoundly that it broke the connection to the server.  Not having recovery of
the connection was no problem for these years, either, but now all these
deficiencies have come to light.

I figured if it didn't like the filter, it would just say so, rather than my
having to replicate its entire parsing mechanism in any client program to avoid
upsetting it.