Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Net::LDAP::Util not compatible with RFC4514

28 views
Skip to first unread message

Quanah Gibson-Mount

unread,
Sep 18, 2012, 7:26:57 PM9/18/12
to perl...@perl.org
In playing with Net::LDAP::Util it became apparent that it is not compliant
with RFC4514, but instead complies with the older RFC2253. Specifically
where #'s in DNs are concerned. Currently it's expecting # followed by hex
digits. This may not be the case once RFC4514 LDIF is in use.

An example DN that it does not handle correctly:

dn: zimbraSignatureName=Signature #1,uid=xyz,ou=people,dc=example,dc=com

The above is not legal with RFC2253, but it is legal with RFC4514.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

Peter Marschall

unread,
Sep 20, 2012, 3:34:36 AM9/20/12
to perl...@perl.org
Hi,

On Wednesday, 19. September 2012, Quanah Gibson-Mount wrote:
> In playing with Net::LDAP::Util it became apparent that it is not compliant
> with RFC4514, but instead complies with the older RFC2253. Specifically
> where #'s in DNs are concerned. Currently it's expecting # followed by hex
> digits. This may not be the case once RFC4514 LDIF is in use.
>
> An example DN that it does not handle correctly:
>
> dn: zimbraSignatureName=Signature #1,uid=xyz,ou=people,dc=example,dc=com
>
> The above is not legal with RFC2253, but it is legal with RFC4514.

You may have a look at the commit
https://github.com/marschap/perl-
ldap/commit/125632a514120ee72912e5fc5b5dd5d1e9c76075
which tries to fix the issue.

The updated ldap_explode_dn() should be more strictly conforming to
the RFCs.
(It is not release ready, because the test files arenot updated yet)

Another issue was found in escape_dn_value() which got fixed in
https://github.com/marschap/perl-
ldap/commit/11ea6b176a0e728d10cc3219cbb84fd8018df5a6

Feedback is very welcome

Best regards
Peter
--
Peter Marschall
pe...@adpm.de

Quanah Gibson-Mount

unread,
Sep 20, 2012, 1:02:05 PM9/20/12
to Peter Marschall, perl...@perl.org
--On Thursday, September 20, 2012 9:34 AM +0200 Peter Marschall
Thanks Peter! Should I look at this or perl-ldap 0.48? ;)

Peter Marschall

unread,
Sep 20, 2012, 1:25:41 PM9/20/12
to Quanah Gibson-Mount, perl...@perl.org
Hi Quanah,

On Thursday, 20. September 2012, Quanah Gibson-Mount wrote:
> --On Thursday, September 20, 2012 9:34 AM +0200 Peter Marschall
> >
> > Feedback is very welcome
>
> Thanks Peter! Should I look at this or perl-ldap 0.48? ;)

At this _and_ perl-ldap 0.48 ;-)
These changes are not part of a release yet.

I am hoping for feedback on the patches, and info from the
openldap mailing list (Kurt co-authored th RFCs) whether my
interpretation of the RFCs is correct.

Best

Peter Marschall

unread,
Sep 21, 2012, 11:52:29 AM9/21/12
to perl...@perl.org, Quanah Gibson-Mount
Hi,

On Wednesday, 19. September 2012, Quanah Gibson-Mount wrote:
> In playing with Net::LDAP::Util it became apparent that it is not compliant
> with RFC4514, but instead complies with the older RFC2253. Specifically
> where #'s in DNs are concerned. Currently it's expecting # followed by hex
> digits. This may not be the case once RFC4514 LDIF is in use.
>
> An example DN that it does not handle correctly:
>
> dn: zimbraSignatureName=Signature #1,uid=xyz,ou=people,dc=example,dc=com
>
> The above is not legal with RFC2253, but it is legal with RFC4514.

Please also have alook at a new alternative solution to the ldap_explode_dn
issue w.r.t. RFC 4514:
https://github.com/marschap/perl-ldap/tree/ldap_explode_dn-relaxed

This alternative tries to adhere to Postel's law, "be conservative in what you
do, be liberal in what you accept from others".

Pro's:
- no additional option (like 'rfc2253') necessary
- should not break existing code that relied on some RFC 2253 peculiarities
(at least, the probability to do so is much lower)
- higher compatibilitiy to openLDAP's slapdn than the other alternative

Con's:
- might accept DN's that are not conforming to any of the RFCs
(but canonical_dn will make them confiorming to both)

Which of the alternatives do you prefer?

Best
PEter

--
Peter Marschall
pe...@adpm.de
0 new messages