On Wed, Feb 12, 2003 at 08:08:20PM -0800, Lucky Green wrote:
> I just spent a few days trying to determine why postfix with STARTTLS
> enabled is instantly dumping core on my new FreeBSD 5.0 machine.
>
> The problem was caused by a conflict between OpenSSL library versions
> 0.9.6 and 0.9.7, both of which are installed on the machine. The former
> as part of the FreeBSD base distribution, the latter as a Port.
>
> Unfortunately, the nature of the conflict, at least on my box, prevented
> any meaningful gdb back trace.
>
> If you are seeing unexplained core dumps with SSL-using applications and
> have both OpenSSL 0.9.6 and 0.9.7 installed, chances are you ran into
> this problem.
>
> Fix:
> no idea.
>
> Workaround:
> 1) Remove one of the two conflicting OpenSSL versions. This may be
> non-trivial; on FreeBSD, a Google search seems to indicate that
> replacing the OpenSSL version that ships with the OS may lead to other
> problems and/or unexpected behavior.
>
> 2) Convince your OS provider to upgrade to 0.9.7.
>
> 3) If you are a Port/Package/RPM maintainer, you may wish to implement a
> check for conflicting OpenSSL library versions.
>
> FYI, FreeBSD is not the only OS on which this problem has been found to
> exist. Debian Linux is experience the same problem. See a post to
> debian-devel-announce attached below.
The problem is picking up the correct library. On HP-UX this is quite
simple. The full name of the library is compiled in. Versioning can be
done by setting the name of the shared library.
serv01 21: chatr /usr/postfix/lbin/smtpd
/usr/postfix/lbin/smtpd:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
internal name:
smtpd
shared library list:
static /usr/postfix/lib/libmaster.1
static /usr/postfix/lib/libglobal.1
static /usr/postfix/lib/libdns.1
static /usr/postfix/lib/libutil.1
dynamic /usr/local/lib/libsasl2.sl.2
dynamic /usr/local/bind/lib/libbind.sl.8.2.7
dynamic /usr/local/lib/libdb.sl
dynamic /usr/local/ssl/lib/libssl.sl.0.9.7
dynamic /usr/local/ssl/lib/libcrypto.sl.0.9.7
dynamic /usr/lib/libc.1
shared library binding:
deferred
global hash table disabled
plabel caching disabled
global hash array size:1103
global hash array nbuckets:3
shared vtable support disabled
static branch prediction disabled
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
data page size: 4K
instruction page size: 4K
OpenSSL does set the soname to the complete library version, so version
conflicts should not occur regardless of the path given during compilation:
...
-Wl,-soname=lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR}
...
Anyway, using distinct paths might be good enough, but:
If an operating system does not manage to remember whether it should load
a library from /usr/lib or /usr/local/lib (given the information it had
during compilation) the operating system is broken. Fix it.
Best regards,
Lutz
PS. OpenSSL versions before 0.9.7 did not officially support shared
libraries. I don't know what soname's might be set by distributors, if
any.
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
