https://bugs.openldap.org/show_bug.cgi?id=10388
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- On Wed, Sep 03, 2025 at 11:58:25AM +0000, openldap-its@openldap.org wrote:
RFC2849:
Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded.
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F ; any value <= 127 except NUL, LF, CR, ; SPACE, colon (":", ASCII 58 decimal) ; and less-than ("<" , ASCII 60 decimal)
However, if the value is not base64 encoded, ldif_parse_line2 (and consequently ldap_parse_ldif_record_x) uses isspace() to just skip any white-space characters at the beginning of at attribute value, icl. tabs. According to the RFC, however, such characters are acceptable. In addition, it does not return an error on LF or CR, just skips them.
On the one hand, LDIFs are supposed to be human readable, and fixing this issue may lead to unexpected problems (e.g a stray tab being added to the attribute value). On the other hand, the standard does not exclude %x01-09 and %x0B-0C as valid characters for a non-encoded value.
How should we proceed?
Hi Nadya, According to the above libldap is allowed to do whatever it wishes when a CR/LF/... are received at the beginning of a value (they might be considered a newline after all) so we can do what we're doing now. For those that are allowed (\t, \v), we have to admit them into the value as intended.
Regards,