Bug 558480 - xmlsec1: bogus lt_dlopen() search path [rhel-4]
Summary: xmlsec1: bogus lt_dlopen() search path [rhel-4]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xmlsec1
Version: 4.8
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Daniel Veillard
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-25 13:40 UTC by Tomas Hoger
Modified: 2013-01-11 02:44 UTC (History)
3 users (show)

Fixed In Version: xmlsec1-1.2.6-3.2
Doc Type: Bug Fix
Doc Text:
Clone Of: 558476
Environment:
Last Closed: 2011-05-04 21:36:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0486 0 normal SHIPPED_LIVE Moderate: xmlsec1 security and bug fix update 2011-05-04 21:36:45 UTC

Description Tomas Hoger 2010-01-25 13:40:29 UTC
+++ This bug was initially created as a clone of Bug #558476 +++

Description of problem:
xmlsec1 uses an embedded copy of libtool's ltdl to lt_dlopen() xmlsec1 wrappers for various crypto libraries (openssl, nss, gnutls).  ltdl version bundled with xmlsec1 is, however, quite old and does not include following upstream commit:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=30ab30e06ad06aad77a478f3f6e51a5db5bfc2f5

Due to that, if xmlsec1 is built on the system with 'include ld.so.conf.d/*.conf' in /etc/ld.so.conf, it will add 'include' and 'ld.so.conf.d/*.conf' to library search path used by ltdl.  Those relative paths are searched after system lib directories (/lib /usr/lib) and hence are only tried when appropriate xmlsec1-<crypto> (or xmlsec1-<crypto>-devel, due to a bug #541599) is not installed.

Note: The above problem affects Fedora / RHEL builds of xmlsec1.  Local builds on system with kernel / kernel-xen packages installed may add additional relative patch to search path, if 'hwcap 0 nosegneg' is listed in one of /etc/ld.so.conf.d/* files (see bug #209930).  That was fixed by libtool upstream via:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b3251f4d7e86d0bd4901de62cd9bcd18ddd7965a

Version-Release number of selected component (if applicable):
xmlsec1-1.2.12-2.fc12

Steps to Reproduce:
Run:
strace -e trace=file /usr/bin/xmlsec1 --verify --crypto FOO /dev/null

Search output for lines as:
open("/lib64/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("include/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("ld.so.conf.d/*.conf/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)

Comment 1 RHEL Program Management 2010-10-22 19:02:11 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 3 Daniel Veillard 2011-04-22 08:29:32 UTC
xmlsec1-1.2.6-3.2 was built with the fix,

Daniel

Comment 6 errata-xmlrpc 2011-05-04 21:36:58 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0486.html


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