From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040803 Description of problem: When importing data from an LDIF file using slapadd or ldapadd, if an entry in the LDIF file ends in a space character, it will BASE64 encode that entry. For example: --- snip --- l: Guildford st: Surrey postalCode: GU2 7YF --- snip --- # Note # - the 'st' entry has a trailing space after the 'y' in Surrey. This entry is then sucessfully imported into the directory, and when queried, returns a BASE64 encoded value. Version-Release number of selected component (if applicable): openldap-servers-2.0.27-17, openldap-servers-2.2.13-32 How reproducible: Always Steps to Reproduce: 1. Create an LDIF file in a standard format, and terminate one of the entries with a space character. 2. Import this into your directory using slapadd or ldapadd. 3. Query the entry you've just added with ldapsearch 4. Notice the entry ending with a space character will be returned in BASE64. Actual Results: [root@station3 root]# ldapadd -x -f base64.ldif adding new entry "uid=jfautley,ou=People,dc=station3,dc=example,dc=com" [root@station3 root]# ldapsearch -x -ZZ '(uid=jfautley)' dn: uid=jfautley,ou=People,dc=station3,dc=example,dc=co street: 10 Alan Turing Road l: Guildford st:: U3VycmV5IA== <<<< Notice the BASE64 encoding postalCode: GU2 7YF [ extra / non-relevant output stripped from the above ] Expected Results: [root@station3 root]# ldapadd -x -f base64.ldif adding new entry "uid=jfautley,ou=People,dc=station3,dc=example,dc=com" [root@station3 root]# ldapsearch -x -ZZ '(uid=jfautley)' dn: uid=jfautley,ou=People,dc=station3,dc=example,dc=co street: 10 Alan Turing Road l: Guildford st: Surrey << Not BASE64'd postalCode: GU2 7YF [ extra / non-relevant output stripped from the above ] Additional info: This bug has been reproduced on RHEL3 AS and RHEL4 ES with the package versions detailed above. These are the latest packages we ship. The only reference I can find to this in the documentation is that if an entry starts with a space character, it will be BASE64 encoded. Thanks to Stuart Sears for assistance in diagnosing this problem. Workaround: Don't terminate your strings with a space character.
The ldapsearch command is formatting the value using base 64 (notice the two colons after the attribute name) as part of the LDIF output. In the directory server, and on the wire, the value is still "Surrey ", as you expected. As you note, this is a documented part of the LDIF specification. There doesn't appear to be a bug here, so I'm closing it.