https://bugs.openldap.org/show_bug.cgi?id=10388
--- Comment #1 from Ondřej Kuzník <on...@mistotebe.net> ---
On Wed, Sep 03, 2025 at 11:58:25AM +0000, openldap-...@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,
--
You are receiving this mail because:
You are on the CC list for the issue.
