NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mod_ssl warning with apache-2.4.46nb1



> Entirely separately from compat, you should be running recent openssl
> anyway, as a matter of security best practices.

That's easy to agree with in principle.  When it gets down to the
practical matters, it's quite another thing. 

Case in point at my end: I have a 9.1_STABLE host which for
various reasons (one failed resize_root, IIRC) which is "tricky"
to do a base OS-upgrade on, i.e. an un-attended reboot will not
succeed.

So I'm left with OpenSSL 1.1.1k from the base OS.

However, solving the "How do ou make pkgsrc apache 2.4.x use
pkgsrc openssl?" issue isn't quite as easy as one could have
hoped for.

Of course, the binary package we distribute for 9.0 for apache24
is linked against the base OS openssl.  So I have to resort to
pkgsrc proper and a local build of apache24 to have any hope of
getting a newer OpenSSL with apache24 without first doing a base
OS upgrade.

2 failed attempts with pkgsrc, 1 finally successful:

1) I added
   PREFER.openssl="pkgsrc"
   to /etc/mk.conf

   make show-var VARNAME=USE_BUILTIN.openssl
   shows "yes" (grr!)

2) I added
   BUILDLINK_API_DEPENDS.openssl+= openssl>=1.1.1o
   just before the include of the openssl buildlink3.mk file
   inclusion in apache24's Makefile.

   make show-var VARNAME=USE_BUILTIN.openssl
   still shows "yes"
   and a rebuild gave me a mod_ssl.so still linked with the base
   OS openssl library.

3) I added
   USE_BUILTIN.openssl=no
   just above the openssl buildlink3.mk file inclusion.
   This finally gave me "no" to the above "make show-var"
   invocation.

However, I get the distinct feeling that neither #2 nor #3 should
be required -- it certainly isn't "the pkgsrc way" to locally
modify the pkgsrc Makefile to get this effect.

At least #3 and a source re-build gave me:

# ldd ./work/httpd-2.4.55/modules/ssl/.libs/mod_ssl.so
./work/httpd-2.4.55/modules/ssl/.libs/mod_ssl.so:
        -lssl.1.1 => /usr/pkg/lib/libssl.so.1.1
        -lcrypto.1.1 => /usr/pkg/lib/libcrypto.so.1.1
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lc.12 => /usr/lib/libc.so.12
        -lrt.1 => /usr/lib/librt.so.1
        -lcrypt.1 => /usr/lib/libcrypt.so.1
# 

and after installing and restarting apache, this gave me when
doing "telnet web-server http":

HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 10 Mar 2023 15:33:59 GMT
Server: Apache/2.4.55 (Unix) OpenSSL/1.1.1s [...]

and that's the pkgsrc openssl on this host.

What is the "supported" method of influencing this?  Is there a
bug in the openssl package's builtin.mk file?  (I can't see it,
but then again, twisty bmake conditionals never was my forte...)

It's often easier to upgrade pkgsrc packages than the base OS,
as the latter typically also involves a kernel upgrade.

So ... our distributing the apache24 package built for 9.0 and
linked with the base OS openssl is in contravention of the stated
best security practice above.  Perhaps the use of pkgsrc openssl
should be conditional on the base OS version?

Regards,

- Håvard


Home | Main Index | Thread Index | Old Index