[Date Prev][Date Next]
Re: Openldap incorrectly? encodes ~ in base64 (ITS#2369)
--On Wednesday, March 12, 2003 2:05 PM -0800 "Kurt D. Zeilenga"
> At 12:39 PM 3/12/2003, firstname.lastname@example.org wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.1.14
>> OS: Solaris 8
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (18.104.22.168)
>> As reported by Anton Ushkov in 2002:
>> We have found that when one of our attributes has a ~ in it, it gets
>> encoded as base64.
> If one assumes the value is a properly encoded directory string
> (and I've done the transcoding properly), 0xC4A0 is the UTF-8
> encoding of LATIN CAPITAL LETTER G WITH DOT ABOVE (U+0120)
> not TILDE (U+007E). The UTF-8 encoding of TILDE is 0x7E.
> But regardless, as the value was represented in valid
> LDIFv1, so I don't see any OpenLDAP software bug here.
After an email discussion with Anton, I realize that I'm actually reporting
something different than he is.
Where he was seeing problems with reads, I'm actually seeing them with
tribes:~> lsearch uid=dane suurirouteto
uid=dane, cn=Accounts, dc=Stanford, dc=edu
The suurirouteto attribute is being incorrectly encoded in base64. This
only happens to suurirouteto attributes in our DB that have ~'s in them.
The process doing the writes is using OpenLDAP 2.0.x ldap libraries. We
have an alternate attribute based on an old schema, called urirouteto,
which is written by a process that uses the Netscape LDAP libraries. It
does not base64 encode urirouteto.
Senior Systems Administrator
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html