Re: Openldap incorrectly? encodes ~ in base64 (ITS#2369)

[quanah@stanford.edu]

--On Wednesday, March 12, 2003 2:05 PM -0800 "Kurt D. Zeilenga" 
<Kurt@OpenLDAP.org> wrote:

> At 12:39 PM 3/12/2003, quanah@stanford.edu wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.1.14
>> OS: Solaris 8
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (171.64.19.82)
>>
>>
>> As reported by Anton Ushkov in 2002:
>>
>> http://www.openldap.org/lists/openldap-software/200201/msg00026.html
>>
>> 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.


Kurt,

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 
writes.

i.e.:

tribes:~> lsearch uid=dane suurirouteto
uid=dane, cn=Accounts, dc=Stanford, dc=edu
suurirouteto=http://rescomp.stanford.edu/~dane/dane.html

more directory0.ldif
/uid=dane
...skipping
uid=dane
suurirouteto:: aHR0cDovL3Jlc2NvbXAuc3RhbmZvcmQuZWR1L8SgZGFuZS9kYW5lLmh0bWw=

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.

--Quanah

--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html