On Thu, Apr 10, 2008 at 12:44:39PM -0400, Joe Kemp wrote:
I am compiling stunnel on Centos 5 that has a regular Openssl 0.9.8b rpm installed. I have put my FIPS openssl in /usr/local/sslfips112.
FIPSLD_CC=gcc /usr/local/sslfips112/bin/fipsld -g -O2 -Wall -Wshadow -Wcast-align -Wpointer-arith -I/usr/local/sslfips112/include -o stunnel file.o client.o log.o options.o protocol.o network.o resolver.o ssl.o ctx.o verify.o sthreads.o stunnel.o auth.o pty.o libwrap.o -lldap -lz -ldl -lutil -lnsl -lpthread -L/usr/local/sslfips112/lib -lssl -lcrypto
This builds a stunnel that seems to run fine. During startup it says "stunnel is in FIPS mode." But if I run "ldd stunnel" it shows it needs /lib/libssl.so.6. While stunnel is running lsof shows it has that library open also. Why does my FIPS stunnel build still use the 0.9.8b shared library? Shouldn't all of the ssl dependencies been handled by the static FIPS openssl library during linking? The same issue exists for libcrypt.
I've never tried to compile a FIPS binary, so this might all be wrong. Grains of salt recommended.
The basic issue is that -lssl doesn't just mean "use libssl.so to resolve symbols while linking". It *also* means "store libssl.so in the table of needed libraries in the final executable". Mostly because the linker has no way of knowing _a priori_ if the executable will eventually try to access some symbol from the library that was not evident during the link (think dlopen)
Adding -Wl,--as-needed to the linker line *ought* to solve this, by telling the linker to only add entries to the needed table for dynamic libraries whose symbols are explicitely required during the link. Beware that libtool likes to reorder args to the linker, and it seems to like putting this option at the end, where it becomes useles. There's a patch at http://bugs.debian.org/347650 that might help with that, but it's not quite for the faint-hearted.
Good luck.