[python-ldap] Ldif parser bug?

[Michael Ströder]

Petr Spacek wrote:
> On 30.9.2015 10:30, Michael Ströder wrote:
>> Tobias Diaz Diaz-Chiron wrote:
>>> Ok, thank you... I'm working on that...
>>>
>>> My LDIF is obtained from a telecom server that send users data in ldif
>>> format. In the ldif some DNs has spaces and some not...
>>
>> Thinking about this FILL some more I wonder how leading spaces in attribute
>> values shall be handled. This might get complex and I'm a bit concerned of
>> interop issues.
>>
>> First try to fix your specific case in LDIFParser._next_key_and_value()
>> probably a *appending* another specific elif clause.
> 
> I do not have reference to spec at hand but I believe that all values starting
> or ending with whitespace should be base64-encoded to avoid ambiguity.

Unfortunately it's not that clear.

From RFC 2849:

      8)  Values or distinguished names that end with SPACE SHOULD be
          base-64 encoded.

This is only a SHOULD and AFAICS it says nothing about leading spaces. So
handling *SPACE as 0 or more space chars would require an lstrip() when
extracting the attribute value after colon. But this might not meet the
expectation of some LDIF producers trying to encode leading space(s) like this:

foo:  bar

And even this will be ambigous:

foo: bar

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150930/63dead23/attachment.bin>