In the mean time I took a closer look at this issue (learning some new things about the ports collection in the process, very cool) and I can only conclude that my first comment was correct, but still based on false assumptions. It's also where
@nodnarb went wrong in his reasoning.
You see; what we all overlooked is that it's not
httpd nor
libapr-1.so.4 which provides support for
https when looking at Apache. That job is reserved for
mod_ssl.so. (I think it was pretty stupid of me to overlook this, but talking after the facts is always very easy).
Looking at my system we can obviously see this situation:
Code:
$ ldd /usr/local/libexec/apache22/mod_ssl.so
/usr/local/libexec/apache22/mod_ssl.so:
[B]libssl.so.6 => /usr/lib/libssl.so.6 (0x801231000)[/B]
[B]libcrypto.so.6 => /lib/libcrypto.so.6 (0x801486000)[/B]
libcrypt.so.5 => /lib/libcrypt.so.5 (0x801827000)
libthr.so.3 => /lib/libthr.so.3 (0x801a46000)
libc.so.7 => /lib/libc.so.7 (0x80081a000)
That's because I prefer to rely on the base system.
Now, there is some truth in my previous comment in that Apache relies on
devel/apr1.
An important detail here is that
devel/apr1 is also part of the
build depends list of Apache. My system relies on the OpenSSL version supplied by the base system, and this is also what
devel/apr1 has been compiled against. Long story cut short: Just using
# make -C /usr/ports/www/apache22 build won't cut it for test casing this because the installed version of
devel/apr1 on my system does not use the OpenSSL port (and I'm obviously not going to replace it on a production system
).
This is a job for
central dogma
(or; my
dogma jail).
So basically I compiled Apache (and it's
devel/apr1 dependency) on a clean system where it automatically installed
security/openssl in the process.
And now we can see for ourselves that Apache really is using the OpenSSL version supplied by the ports collection:
Code:
# pwd
/usr/ports/www/apache22/work/httpd-2.2.25/modules/ssl/.libs
# ldd ./mod_ssl.so
./mod_ssl.so:
[B]libssl.so.8 => /usr/local/lib/libssl.so.8 (0x801231000)[/B]
[B]libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801497000)[/B]
libc.so.7 => /lib/libc.so.7 (0x80081a000)
libthr.so.3 => /lib/libthr.so.3 (0x80186a000)
Now, to complete my story lets also check out what
httpd and
libapr-1.so.4 are using in this environment:
Code:
# pwd
/usr/ports/www/apache22/work/httpd-2.2.25
# ldd ./httpd
./httpd:
libm.so.5 => /lib/libm.so.5 (0x800876000)
libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x800a97000)
libaprutil-1.so.5 => /usr/local/lib/libaprutil-1.so.5 (0x800cfa000)
libdb-4.2.so.2 => /usr/local/lib/libdb-4.2.so.2 (0x800f1e000)
libgdbm.so.4 => /usr/local/lib/libgdbm.so.4 (0x801204000)
libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80140b000)
libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x801615000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x801839000)
libapr-1.so.4 => /usr/local/lib/libapr-1.so.4 (0x801b35000)
[B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x801d61000)[/B]
libthr.so.3 => /lib/libthr.so.3 (0x801f80000)
libc.so.7 => /lib/libc.so.7 (0x8021a2000)
# cd /usr/ports/devel/apr1/work/apr-1.4.8/.libs
# ldd ./libapr-1.so.4
./libapr-1.so.4:
[B]libcrypt.so.5 => /lib/libcrypt.so.5 (0x80122c000)[/B]
libthr.so.3 => /lib/libthr.so.3 (0x80144b000)
libc.so.7 => /lib/libc.so.7 (0x80081a000)
As such, my previous simple conclusion was indeed too simplistic (as I somewhat expected, thus my comment that I'd be diving deeper into this).
There was nothing going wrong, we were just looking in the wrong places.
Man, I
love stuff like this. Honestly guys; it may look tedious or such, but
never underestimate the stuff you can learn from going over all this. It's just awesome in my opinion.
