Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157309 - Import of LDIF file causes entries to be BASE64 encoded when they end in a space character
Summary: Import of LDIF file causes entries to be BASE64 encoded when they end in a sp...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap
Version: 4.0
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Jay Fenlason
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-10 14:56 UTC by Jon Fautley
Modified: 2015-01-08 00:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-11 15:35:17 UTC


Attachments (Terms of Use)

Description Jon Fautley 2005-05-10 14:56:29 UTC
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 15:35:17 UTC
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.