https://bugs.openldap.org/show_bug.cgi?id=10388
Issue ID: 10388 Summary: ldif_parse_line2 is not compliant with RFC2849 Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs@openldap.org Reporter: nivanova@symas.com Target Milestone: ---
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?
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,
https://bugs.openldap.org/show_bug.cgi?id=10388
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@openldap.org |nivanova@symas.com Keywords|needs_review | Target Milestone|--- |2.6.11
https://bugs.openldap.org/show_bug.cgi?id=10388
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu hyc@openldap.org --- There is no bug here, the code is correct.
You're missing the earlier definitions:
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" ( FILL 0*1(SAFE-STRING) / ":" FILL (BASE64-STRING) / "<" FILL url)
FILL = *SPACE
All spaces after the colon are fill characters and are properly stripped.
https://bugs.openldap.org/show_bug.cgi?id=10388
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |UNCONFIRMED
--- Comment #3 from Howard Chu hyc@openldap.org --- Oh I see, you're talking about the tab character being a valid character in a value. Never mind previous comment.
-
openldap-its＠openldap.org