Bug 157309 - Import of LDIF file causes entries to be BASE64 encoded when they end in a space character
Import of LDIF file causes entries to be BASE64 encoded when they end in a sp...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap (Show other bugs)
4.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jay Fenlason
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-10 10:56 EDT by Jon Fautley
Modified: 2015-01-07 19:09 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-11 11:35:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jon Fautley 2005-05-10 10:56:29 EDT
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.
Comment 1 Nalin Dahyabhai 2006-08-11 11:35:17 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.